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

[schalk]

I see merit in this idea. However propose the uri format below:

Request Uri:
bitid:auth?bitid_address=1FZp4L1EzCtwLPZxbvopwgqBwVDzox1nxA&bitid_callback=http://example.org/login?name=Schalk

bitid_address is an optional field. If bitid_address is not provided, it will allow the user to select from multiple addresses in their BitID Mobile App repository.
bitid_callback this is a required field and is the uri called after the bitid has done it's crypto magic.

Then the request uri is called, the BitId Mobile App will append a generated a nonce (a random string), the timestamp and the bitid_address to the callback uri yielding a uri like:
http://example.org/login?name=Schalk&bitid_nonce=e15f9428-e24c-4bf5-947f-0941cd604894&bitid_timestamp=1397192899&bitid_address=1FZp4L1EzCtwLPZxbvopwgqBwVDzox1nxA

the BitId Mobile App will then sign that uri and appended the signature to the uri yielding a uri like:
http://example.org/login?name=Schalk&bitid_nonce=e15f9428-e24c-4bf5-947f-0941cd604894&bitid_timestamp=1397193115&bitid_address=1FZp4L1EzCtwLPZxbvopwgqBwVDzox1nxA&bitid_signature=HI/AuQMCo2gC49u+523oqTJDbNTDB/JbsaPZyLHmoYx83f1+fY5OU1zXAuPRD8QW7VLmrtDpKt+G1/oyBeF7+1w=

the mobile phone will then open that uri, which in the above example would open the web browser on the device, but in the case of a uri like:
cointalk:?name=Schalk&bitid_nonce=e15f9428-e24c-4bf5-947f-0941cd604894&bitid_timestamp=1397193115&bitid_address=1FZp4L1EzCtwLPZxbvopwgqBwVDzox1nxA&bitid_signature=HI/AuQMCo2gC49u+523oqTJDbNTDB/JbsaPZyLHmoYx83f1+fY5OU1zXAuPRD8QW7VLmrtDpKt+G1/oyBeF7+1w=

This would launch the CoinTalk application and log the user in.

I introduced a timestamp as then you only need to keep track of a very limited number of nonces. Depending on how the server is setup, it might only allow timestamps which are up to a minute before the timestamp in the request, this means you only have to store the nonces for the last minute. If this timestamp field wasn't there you would have to store all the nonces since the user registered and compare against them each time.

[1714911160]

1714911160

[1714911160]

1714911160

[1714911160]

1714911160

[fbueller]

Do it with a BIP32 extended public key, and you would get a challenge for a different key every time.

[EricKennedy]

The demonstration site now integrates the possibility of simulating wallet's response via a curl command.
http://bitid-demo.herokuapp.com/

You need to click on login to get a nonce and you can then build the callback :

Code:

curl -X POST http://bitid-demo.herokuapp.com/callback \
  --header "Content-Type: application/json" \
  --data '{"uri" : "bitid://bitid-demo.herokuapp.com/callback?x=6d9a980a07911624", 
    "address" : "xxx", 
    "signature" : "xxx"}'

The message to sign being for instance :

Code:

Bitcoin Signed Message:
bitid://bitid-demo.herokuapp.com/callback?x=6d9a980a07911624

When you send the POST to the callback URL, the front end will autolog.
The UX is very smooth.

What we need now is to have a first wallet implementing BitID.

Eric

[EricKennedy]

A ruby gem implementing challenge and signature management (for the back end) has been released today :
https://github.com/bitid/bitid-ruby

[btchip]

Starting to look into it as discussed, I have a minor concern with what's getting signed

The message to sign being for instance :

Code:

Bitcoin Signed Message:
bitid://bitid-demo.herokuapp.com/callback?x=6d9a980a07911624

because we end up considering the magic "Bitcoin Signed Message:\n" twice, once in the message we plan to sign, a second time by the wallet itself (which will sign specifically \x18 | Bitcoin Signed Message:\n | message size coded as a bitcoin varint | message) so it might look a bit confusing to the implementing party, and signing the URL alone looks closer to what you expected. What's your take on that ?

also, you can disregard the comment I made earlier during the discussion regarding the message length - this is now different in Armory and obviously a brainwallet brainfart  

[EricKennedy]

because we end up considering the magic "Bitcoin Signed Message:\n" twice, once in the message we plan to sign, a second time by the wallet itself (which will sign specifically \x18 | Bitcoin Signed Message:\n | message size coded as a bitcoin varint | message) so it might look a bit confusing to the implementing party, and signing the URL alone looks closer to what you expected. What's your take on that ?

Yes you are right. Another reason is that the content of the QRcode must starts by bitid:// otherwise the intent wouldn't be fired.
If this is confusing, it's because of the manual process, where I have to give to the user the exact text to sign using the message signing feature.

Where can I find more documentation about the "\x18 | Bitcoin Signed Message:\n | message size coded as a bitcoin varint | message" specifications ?
Cause I didn't know about the \x18 and the varint.

Also, do you know why it is not used when you sign a message in Bitcoin Core for instance ?
What is in fact the use case of adding "Bitcoin Signed Message" etc ?

Eric

[EricKennedy]

Ok, I cleaned all the confusion about "bitcoin signed message" stuff.
The BIP draft as well as all the code is now much clearer.

So basicaly what you always need to sign is the URI :

Code:

bitid://bitid.bitcoin.blue/callback?x=9b494d01b5034ed3

The "Bitcoin Signed Message" is integrated into the signing procedure (wallet side) and verifying (back end side).

Thanks for clearing this mess

Eric

[EricKennedy]

Android Bitcoin Wallet has a first implementation of the BitID protocol :
https://github.com/bitid/bitcoin-wallet

A short video showing the user flow :
https://www.youtube.com/watch?v=3eepEWTnRTc

[Mitchell]

Congrats dude! I really hope that more wallets implement it and that websites are going to use it.

[NanoAkron]

Android Bitcoin Wallet has a first implementation of the BitID protocol :
https://github.com/bitid/bitcoin-wallet

A short video showing the user flow :
https://www.youtube.com/watch?v=3eepEWTnRTc

Very good demonstration of a very good idea.

How are discussions progressing with the Core developers to get this pulled into an upcoming version as an additional Core functionality?

[dewdeded]

Where is the problem for this solution?

There are more then enough avaible (or dead) auth methods/projects. No need to bloat the Core(!) client with this and no need to waste the time of the core devs.

Code your own tool/client/fork whatever IHMO.

[marcus_of_augustus]

Did you consider using a stealth address instead of the public address for the initial connection request (which is in plain text) ?

[EricKennedy]

Did you consider using a stealth address instead of the public address for the initial connection request (which is in plain text) ?

If the address is created on the fly at the initial connection request and is therefore not linked to anything, what would be the benefit of using a stealth address ?
I may not correctly grasp the concept of stealth address but I can't see how they could add any privacy advantage in this particuliar setup ?

[NanoAkron]

Where is the problem for this solution?

This has the potential to bring 2FA-level security to every login, without the need for a centralised service.

[EricKennedy]

There is now a Python implementation of the back end library :
https://github.com/LaurentMT/pybitid

Presentation of BitID metadata (leveraging BIP70, allowing 2FA, ...) :
https://github.com/bitid/bitid/blob/master/bitid_metadata.md

[ecrick3]

any1 try Python implementation yet?

[laurentmt]

any1 try Python implementation yet?

Hi ecrick3,
laurent here (the guy who started to wrote the python implementation). Since the first release on github, I've done some more tests and modifications to strenghten the library. Moreover, there's now a python implementation of the demo app written by EricKennedy in ruby. You can get the code here. I've tried to comment the code as much as possible to illustrate the different steps of the protocol. If you're a python developer and interested to participate in the development, you're also very welcome !

[gacrux]

A big problem on the internet today is the cheapness of identity. Many sites struggle with a constant influx of trolls and sock-puppets. We attempt to address this with:
* Forum reputation systems - but there's still no easy way for a new user to prove they have anything invested in their identity.
* The ubiquitous CAPTCHA, just to establish that a visitor is a human - the very lowest bar we can put up, and even that is constantly being eroded, and causes problems for visually impaired users.

If I'm using a bitcoin address to sign in to a website, the site now has some extra information about me:
* the amount of BTC I control with that address
* the coin age

Or, put another way, the site can predict:
* the number of "Bitcoin Days Destroyed" that would occur if I were to hypothetically move the coins to another address I control in a self-payment.

So an address with 2 BTC in it for the last 5 days gets a score of 10, an address with 0.5 BTC in it for the last 21 days gets a score of 10.5, etc.

If this score is high enough you don't need to bother me with a CAPTCHA. You can also initialise forum reputation based on this score, etc etc. It'd be useful for all kinds of applications where anonymous identity is desired but the cheapness of identity creation causes problems (eg. distributed markets?)

Of course, I don't want to keep a significant balance in a wallet accessible by my browser. But I could:
* sign my BitID address with my main (perhaps offline) wallet address(es)
* provide these signatures to the server while negotiating BitID login

The server could then establish a score for my identity (coins in signatory addresses * coin age) - the higher the score, the less likely I am to be engaging in abusive behaviour. If I do engage in abusive behaviour then:
* the server adds all the signatory addresses to a blacklist (either internal, or perhaps shared with other sites somehow)
* assigns a zero/negative score to any BitID that provides any blacklisted signature upon login in future

If I wanted to dodge the blacklist and continue to engage in abusive behaviour, I'd need to move the coins to a new address. This effectively resets my "Bitcoin Days Destroyed" score to zero, and I need to wait for it to accumulate again, thus braking (rate limiting) my behaviour.

How high the bar needs to be (score of 5? 100? 0.1?) would be established by individual site operators for their own sites through trial and error.

Please consider extending your BIP to cover this. It would provide an additional factor to motivate adoption of your authentication scheme for relatively little added cost.

[EricKennedy]

It would provide an additional factor to motivate adoption of your authentication scheme for relatively little added cost.

This approach is interesting, but I can't see how having coins for a long time on an address is related to small probability of abusive behavior ?
I understand that if you troll you'd get banned and then in the long term it would converge to the expected relation, but from day one it wouldn't work at all.

The other possible solutions to avoid CAPTCHA are :

• Coin sacrifice
• send a not trivial amount to the service in escrow (2 of 2 multisig)
• just pay the service 0.001 BTC (for instance) to unlock privileges

Another approach is to delegate the identity to another protocol such as the Identity Protocol from Mike Hearn.

Eric

[laurentmt]

@gacrux I agree with you that protocol specs should address spam issue server side (actually, we already had this discussion with Eric ) but I agree with Eric that we can imagine several solutions to avoid spam and that each website should be able to implement the solution which best fits its needs.

On my side, I can imagine this use case:
- I want to buy a movie on a VOD website.
- I pay it with bitcoin.
- The website checks the blockchain (or via BIP70) to retrieve paiements sent by customers and match them with purchases.
   All input addresses used as sources of paiements can be used to sign in with the website and access the movie.
- I sign in with one of the input addresses of my tx. Popcorn time !

Benefits :
- I don't need to leak personal informations (login, password, identity, credit card, ...) to watch my movie.
- BitId is "off-blockchain": BitId using addresses already used for paiements does not leak more data into the blockchain.
- The website already knows the tx and the input addresses. BitId does not leak more data to the retailer.

For websites like forums I could imagine something like a micro-tx sent to the forum before sign out but may be something like what you described
could be a more advanced system to fight trolling. Concerning privacy concerns, I would mix some coins with coinjoin (or another) before sending the micro-tx.

So, my take is that we should make sure that websites think to address the potential spam issue and may be propose different anti-spam concepts which will be more or less adapted to the needs of websites. But websites should be free to implement what seems the best solution for them.