[BIP][Draft] BitID - "Connect with Bitcoin" protocol

[EricKennedy]

Request for discussion

Code:

BIP: TBD
Title: Bitcoin address authentication protocol (BitID)
Author: Eric Larcheveque, @EricLarch
Status: Pre-draft
Type: Process
Created: TBD

This BIP is placed in the public domain.

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

Slides presentation :
http://bit.ly/bitid-slides

Video demo :
https://www.youtube.com/watch?v=3eepEWTnRTc

Abstract

The following BIP is an open protocol proposal allowing simple and secure authentication based on public key cryptography. 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.

Motivation

Bitcoin related sites and applications shouldn’t have to rely on artificial identification methods such as usernames and passwords. Using a wallet for authentication purposes has many benefits :

• "one-click" registration and login procedures
• no need to remember or duplicate passwords
• the server only knows and stores the users's Bitcoin public address
• services always know the return address
• optionally, connect to a decentralized identification system in order to populate registration fields (nickname, email ...)

Specification

In order to access a restricted area or authenticate oneself against a given service, the user is presented with a QRcode containing the following URI :

Code:

bitid://www.site.com/callback?x=NONCE

• bitid is the protocol scheme
• x is the NONCE, must always be unique, and will be the user's session ID on the site the callback is redirected to
• the url is the callback, https required

By scanning the QRcode or clicking on it (through scheme registration), a wallet will provide the user with an interface showing the authentication request details.
If agreeing, the user must pick or create a Bitcoin public address. The wallet will sign the URI with the address' private key and POST address, uri and signature to the callback URL.

The receiving server verifies the validity of the signature and proceeds to authenticate the user by her public bitcoin address.

A manual signing back channel is available in case the user doesn't have a compatible wallet.

For more details please refer to :
https://github.com/bitid/bitid

The complete specification will be integrated into this BIP after discusssions.

Rationale

Classical password authentication is an insecure process that could be solved with public key cryptography. The problem however 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.

Backward compatibility

Message signatures are already implemented in various wallet applications. Manually signing a challenge is therefore available immediately, at the cost of a cumbersome user experience.

Reference Implementation

A demonstration of the workflow is available here :
http://bitid.bitcoin.blue

Right now, only manual signatures are available as there is not yet a wallet implementing this BIP.

Source code of the demonstration service :
https://github.com/bitid/bitid-demo

Ruby gem implementing challenge and signature :
https://github.com/bitid/bitid-ruby

See also

Reddit thread on the need of such a protocol :
http://www.reddit.com/r/Bitcoin/comments/1nkoju/bitcoin_core_dev_websites_do_not_need_passwords/

SQRL, a similar proposal not limited to Bitcoin :
https://www.grc.com/sqrl/sqrl.htm

[1714790076]

1714790076

[Mitchell]

I like this. A lot. Just tried it on your demonstration page (with manual signing) and I believe that something like this would be a big improvement. It would at least make signing into a Bitcoin related websites a lot easier.

[EricKennedy]

You probably want to do this on github and do a pull request and let people discuss it. https://github.com/bitcoin/bips

From my understanding, I thought it was recommended to first open a discussion on the subject, and to submit a real BIP only if some positive consensus was reached.

To be honest this is too niche to be included in the bitcoin client at this time, and will probably be shot down. Instead just develop it on your own and convince people to put it into their wallet systems.

Each Bitcoin user will at one time or another be in the situation to register on a Bitcoin enabled website or service. Being able to facilitate this process could be a huge win for the ecosystem.

I started by talking to wallet developpers, and in fact it fast tracked me to draft a BIP :
https://bitcointalk.org/index.php?topic=293472.msg6064139#msg6064139

[Jan]

First of all, this is a great idea. In many ways it looks like something I have been toying with myself 

Username/passwords are old-school, error prone, and insecure. There has been many attempts to introduce public key authentication for normal users over the years, but handling secret stuff is hard to do in a way that makes it easy & secure. With Bitcoin we already have to solve these things, so to bitcoiners this is like a free lunch because we can piggyback on our existing technology. So Eric, thanks for taking on the challenge of turning this into a BIP.

Suggestions:

• The double slash in "bitid://" is a http thing, and not necessary, so you can make it "bitid:" just like we have "bitcoin:". Most wallets support "bitcoin://" in addition to "bitcoin://" because of a misunderstanding during the early days
• I wouldn't use the nonce as the (secret) session ID after successful authentication. Instead it should return a longer, random, and secret session ID in the POST response
• In fact I would probably remove the nonce from the URI and get it from the server over https. This is to prevent some sucker from giving you a chosen nonce. First do a GET to https://www.site.com/blah/nonce?a=18JFzYgLH3kbweCqJzLZPteqysvup5qwTu to get a nonce linked to your bitcoin address, followed by a POST to https://www.site.com/blah/authenticate?a=18JFzYgLH3kbweCqJzLZPteqysvup5qwTu and let the signature be part of the POST data. On success the (unique, secret, random) session ID is part of the POST response
• Hmm...  the site name might not even be URL encoded as a HTTP parameter. Why not do it like this: "bitid:www.site.com/blah" ? Much cleaner and very readable
• The signature should contain the bitid URI, the nonce,  and be prefixed with"Bitcoin Signed Message:\n" like any other Bitcoin signed message

Off the top of my head I would do it like this in Mycelium:
1. User scans a bitid QR code from a desktop browser or clicks a bitid URI in the browser of his phone. This launches the wallet.
2a. If the site (htttps://www.site.com/blah) is already associated with an address in the wallet, then the user will be asked "Would you like to login to www.site.com/blah as 18JFzYgLH3kbweCqJzLZPteqysvup5qwTu ?" If the address has a label ("Fred")in the wallet the label will get displayed instead of or in addition to the Bitcoin address)
2b. If the site (htttps://www.site.com/blah)  is not associated with an address in the wallet, then the user will see "You are about to login to www.site.com/blah. Which Bitcoin address would you like to use?". User picks/creates an address in the wallet
3. The user clicks "Login". If the wallet has the private key it does the login dance (GET nonce, calculate signature, POST signature) If the wallet does not have the private key (read-only wallet) it asks the user to scan the private key from paper (cold authentication), does the login dance and wipes the private key from memory.
4. On success the wallet closes and returns to the browser, which automatically updates with "Welcome Fred"

... or something like that.

[instagibbs]

Would it make sense to use a master public extended key from a wallet chain in from an HD wallet?

That way, you could have a wallet chain for "Overstock Payments", and use the master public extended key to demonstrate ID. Whenever you send a payment from that wallet it doesn't even have to ask you.

[EricKennedy]

The double slash in "bitid://" is a http thing, and not necessary, so you can make it "bitid:" just like we have "bitcoin:". Most wallets support "bitcoin://" in addition to "bitcoin://" because of a misunderstanding during the early days

Yes, :// are for locations ; I updated to have "bitid:"

I wouldn't use the nonce as the (secret) session ID after successful authentication. Instead it should return a longer, random, and secret session ID in the POST response
In fact I would probably remove the nonce from the URI and get it from the server over https. This is to prevent some sucker from giving you a chosen nonce. First do a GET to https://www.site.com/blah/nonce?a=18JFzYgLH3kbweCqJzLZPteqysvup5qwTu to get a nonce linked to your bitcoin address, followed by a POST to https://www.site.com/blah/authenticate?a=18JFzYgLH3kbweCqJzLZPteqysvup5qwTu and let the signature be part of the POST data. On success the (unique, secret, random) session ID is part of the POST response

This adds slight complexity in the implementation. This would be to prevent anyone to forge a bitid with a chosen nonce, but what benefits does it make ? I mean, what security risk does it create to be able to chose the nonce ? If the wallet signs the full URI it cannot be exploited in any case.
I think we should implement the GET / POST only if there is a real security exploit possible. The simpler, the better.

Hmm...  the site name might not even be URL encoded as a HTTP parameter. Why not do it like this: "bitid:www.site.com/blah" ? Much cleaner and very readable

Yes, it's much cleaner. I'm not sure there is a real need to have an action ("login"), as I can't think of another different action.

The signature should contain the bitid URI, the nonce,  and be prefixed with"Bitcoin Signed Message:\n" like any other Bitcoin signed message

I've had some remarks that Bitcoin message should always be on the format :
"[Timestamp] [Human readable text]"

For instance : "2014-04-04 11:21 I agree to connect to site.com on session NONCE"

If this is needed then the bitid URI needs to also contain this text as it cannot be created by the wallet.

Off the top of my head I would do it like this in Mycelium:
...

Totally agree on the flow ! Simple and efficient.

After POSTing the results, the wallet should just close. The back end will push the front end (browser) and autolog the user. The POST is API post and not a browser session.
If you authenticate out of band, you are not on the same computer anyway.

[Rassah]

Is this basically this https://www.grc.com/sqrl/ but with bitcoin keys instead of PGP?

[EricKennedy]

Is this basically this https://www.grc.com/sqrl/ but with bitcoin keys instead of PGP?

Yes, as stated into the document SQRL is "prior art" but it is not suited for usage as is.
The proposal is much more about the UX and integration into wallets than a real protocol innovation.

Eric

[Portnoy]

I really like this idea!   

[Rassah]

Is this basically this https://www.grc.com/sqrl/ but with bitcoin keys instead of PGP?

Yes, as stated into the document SQRL is "prior art" but it is not suited for usage as is.
The proposal is much more about the UX and integration into wallets than a real protocol innovation.

Eric

Not disparaging, on the contrary, i'm a huge fan of SQRL, and was hoping for something  that with bitcoin ever since #bitcoin-otc implemented message signing for logins.

[benjyz]

good idea, but bitcoin is showing its limits. there is a choice to be made: either you go with centralization through certificates. or you don't. the decision has been made, and so bitcoin will from now on carry on with this very weird identity system we call the internet. address as a proxy is perhaps a viable idea, but as Mike Hearn pointed out, this neglects the fact that in quite a few instances people use proxies, such as coinbase, blockchain.info, etc. so if you weight possible downsides through unexpected attacks against the upside - a somewhat more simple login mechanism - I doubt that there will be much enthusiasm. the consensus of the development crowd is in favor of SSL and CA's, and against web-of-trust. Peter Todd and Gregory Maxwell tend to argue for WoT, but it is not implementable today and making large changes in the protocol is not covered by consensus. perhaps there are some clever hacks to do more interesting things, but it seems unlikely to me. bitcoin will remain a very good store of value, but the window for experimentation is pretty much closed by now.

[Peter Todd]

Peter Todd and Gregory Maxwell tend to argue for WoT

That's incorrect. We've been arguing for making WoT, CA's, and combinations of the two available to suit user needs. CA is fine when your security needs are low; when you're buying a coffee CA security is more than good enough. When you're moving $1k worth of Bitcoins you might want to double-check, $10k probably, and $1,000,000 you'd be downright negligent to rely only on CA's. Fortunately the same OpenPGP technology can easily support all these models.

Of course, remember that if you're writing Bitcoin software, it's really easy to be in a situation where millions of dollars worth of value are controlled by your software. That's why the Bitcoin sourcecode and binaries are protected by both OpenPGP and CA's.

[Carlton Banks]

Of course, remember that if you're writing Bitcoin software, it's really easy to be in a situation where millions of dollars worth of value are controlled by your software. That's why the Bitcoin sourcecode and binaries are protected by both OpenPGP and CA's.

Yup, when updating to 0.9.0 on my main wallet, I:

• Checked certificate/signature for bitcoin.org
• Verified SHA256.asc file
• Ran the hashing checksum on the tarball

And I do not see a reason not to check the website certificate, even if it's the simplest/weakest security on offer. You want every assurance you can get if it's where most of your coins are stowed. Should really go to the CA website and try to find fingerprints to compare with manually, but I think the browser is doing that automatically anyway, so it would be a peace of mind thing more than anything.

[soullyG]

Great idea - I look forward to hearing more about this in the future!

[vane91]

you mean this:
nameid.org
onename.io
but with qrcodes, right?

[EricKennedy]

you mean this:
nameid.org
onename.io
but with qrcodes, right?

Nameid and onename are services to attach an identity to a username or a key.
You cannot "connect with onename" on a website, in the same way you can "connect with google" or "connect with Facebook"

BitID is about authenticating a session.
Nameid and onename could be used with BitID.

For instance :
1. I login on a website using BitID ; the website starts a secure session authenticated by my bitcoin address
2. using nameid or onename (or another service), I link the bitcoin address with an identity (name, email, etc)

[EricKennedy]

Would it make sense to use a master public extended key from a wallet chain in from an HD wallet?
That way, you could have a wallet chain for "Overstock Payments", and use the master public extended key to demonstrate ID. Whenever you send a payment from that wallet it doesn't even have to ask you.

This makes a lot of sense, and the consensus on the bitcoin-dev mailing list would be to explore this direction.
I'm working in adding this feature to the protocol, so you could auth either with a Bitcoin address or with a master key (i.e. deterministic seed)

[renee25]

you mean this:
nameid.org
onename.io
but with qrcodes, right?

Nameid and onename are services to attach an identity to a username or a key.
You cannot "connect with onename" on a website, in the same way you can "connect with google" or "connect with Facebook"

BitID is about authenticating a session.
Nameid and onename could be used with BitID.

For instance :
1. I login on a website using BitID ; the website starts a secure session authenticated by my bitcoin address
2. using nameid or onename (or another service), I link the bitcoin address with an identity (name, email, etc)

yes you can connect with openid, check it out.


How do I sign into an OpenID-enabled site?

Simply enter https://nameid.org/ into the login-box. You will be redirected to NameID where you can log in with your name, and if that is successful, you will be returned to the OpenID consumer site, where you are then authenticated with your identity.


from what i understand, there is little difference, just that it directly opens your wallet, with nameid you need:


What do I need in order to use NameID?

First of all, you need a Namecoin identity, and need the wallet that owns it on your local system. Second, you need Namecoin installed and running with the server=1 configuration flag, and need to be able to perform signmessage commands with it. Don't worry though, you can install the NameID Easy Login add-on for Mozilla browsers, which takes care of the signing for you. And finally, you need some OpenID-enabled sites you want to sign into.

there is not yet a wallet implementing this BIP.

Yep, that's the problem. Also no websites using bitid:xxx
You need to make your system work with openid, because who is going to add another login scheme to their websites.

[renee25]

Yup, when updating to 0.9.0 on my main wallet, I:

• Checked certificate/signature for bitcoin.org
• Verified SHA256.asc file
• Ran the hashing checksum on the tarball

irony mode off

fixed

[NanoAkron]

Yep, that's the problem. Also no websites using bitid:xxx
You need to make your system work with openid, because who is going to add another login scheme to their websites.

Because bitcoin has been featured in newspapers and on TV channels around the world, and OpenID hasn't.

User recognition is everything. If 'login with bitcoin ID' becomes a thing, micro payments will follow, and the ecosystem will grow even further.