Topic: [BIP][Draft] BitID - "Connect with Bitcoin" protocol - page 8. (Read 22743 times)

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

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


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.


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.


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.


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.

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.

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.

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.


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://bitcointalksearch.org/topic/m.6064139

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

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.

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.

Request for discussion


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 :

• 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