Bitcoin Forum

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

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.

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://bitcointalk.org/index.php?topic=293472.msg6064139#msg6064139

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

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.

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.

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.

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

I really like this idea!   8)

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.

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.

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.

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.

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

you mean this:
nameid.org (https://nameid.org/?view=login)
onename.io (http://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)

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)

yes you can connect with openid, check it out (https://nameid.org/?view=faq).


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.


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.

fixed

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.

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.

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

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 :


The message to sign being for instance :


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

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

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


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

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

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 :


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

Thanks for clearing this mess :)

Eric

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

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

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?

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.

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 ?

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

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

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 (https://github.com/LaurentMT/pybitid_demo). 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 ! :)

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.

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 (https://en.bitcoin.it/wiki/Identity_protocol_v1#Creating_sacrifice_transactions)
• 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 (https://en.bitcoin.it/wiki/Identity_protocol_v1) from Mike Hearn.

Eric

@gacrux I agree with you that protocol specs should address spam issue server side (actually, we already had this discussion with Eric ;D) 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.

Abusive behaviour isn't the problem I want to fix - /cheap identity creation/ is.

Abusive behaviour is easily dealt with by simply banning the user. A problem only arises when the user has nothing invested in the account that you banned, so can simply create a new account and come back.

(coin age * balance) is a very good proxy for investment in an identity, because you can't repeatedly fake it. Sure, everybody starts with some reputation, even the bad guys. But the bad guys only get one chance to burn up their reputation, then acquiring more will be very slow.



He'd get banned very quickly, and then not come back (well, not without significant resources + time to throw at the problem.) I'm not talking about a 100% bulletproof solution, just cheaply raising the bar.



My objections to the sacrifice approach are:
* the bootstrapping problem: real upfront costs to users to participate a new, as-yet-unestablished mechanism, will prevent it gaining significant traction
* the fluctuating value problem: a sacrifice of 1 BTC right now represents about USD$440. A sacrifice of 1 BTC in Janurary might have represented closer to $1000; in Janurary last year, ~$17. Measuring sacrifices is non-trivial, requires knowledge of historical exchange rates.

Objections to the other two - escrow with the website, or outright micro payment - are similar:
* bootstrapping problem: too complex / expensive to gain significant usage
* requires funds in a hotwallet, which may be vulnerable to theft
* requires the client to have access to the blockchain / actually broadcast transactions

By comparison, what I'm suggesting:
* requires the client to simply have some signatures which prove control of funds, nothing more. The BitID authentication remains very simple (just a few extra bytes to transmit.)
* client requires no hot wallet, no knowledge of blockchain, makes no transactions.
* requires new users to simply have a bitcoin balance somewhere, which most already do (even cold storage - as long as they have access to the private key to sign their BitID to prove control of funds.)

Think about it. Most bitcoin users probably already have control of an address:
A) with significant funds
OR:
B) with even a small amount of funds that haven't moved for a very long time
OR:
C) both (ie. your typical cold storage user)

They could just sign a simple message (eg. bitcoin-qt has a feature to sign arbitrary messages with private keys from your wallet) that says "My BitID is: XYZ", cut-and-paste the output into the client software they use for BitID (browser plugin, whatever.) And - bingo - instant reputation everywhere they use BitID.

A universal measure of how much a user has invested in their current ID should be very generally applicable. I think it belongs in the auth protocol. When I sign in with BitID the server should just have that "likelyhood of uniqueness" weighting available to it for free. I need only transmit a few bytes during authentication and it'd be available. It's then up to the server whether it wants to make use of that information or not.


Completely tangential use case sorry :) If the user is paying you for goods/service then you don't care if they do it 100x - as long as they're paying you every time :P When was the last time you typed in your visa card number and then got presented with a CAPTCHA? The fact that you've just presented payment is all the proof most people want that you're serious about the transaction.

Think instead of something like this forum, where account creation is free:
1. create account
2. troll / scam like crazy
3. acquire negative reputation
4. ditch account, GOTO 1, rinse & repeat.

That's pretty common. How can we combat it? One idea is to make newly created accounts start with negative reputation (or restricted to posting in a newbies area, or whatever.) But then genuine new users face an uphill battle to distinguish themselves from the trolls and scammers, and to build up a reputation.

/I'm just suggesting one cheap way that we could distinguish them./

If the user can show signatures proving control of a suitable amount of aged coins (the more coins the better / the older the better), that we haven't ever seen before, then they're /probably/ a genuine new user.

In the case of a forum, we might grant that "probably genuine" new user a positive starting reputation, whereas an unverified new user (more likely to be a troll/scammer creating throwaway accounts) starts with default lower reputation. We're just sorting the sheep from the goats, if you see :)

In the case of, eg. an email service, we could allow the "probably genuine" new users to skip the CAPTCHA (ie. if their [balance * coin age] score meets a certain configurable threshold.) The CAPTCHA is designed to prevent an automated script from creating thousands of accounts, right? Such an automated script is very unlikely to be able to provide thousands of unique high/aged BTC balances.

Yes, the spammer could invest in an enormous amount of BTC, split it into thousands of addresses, and then wait for a few months for it to age enough to perform his attack. All the site admin needs to do to respond is bump the threshold up. He can quickly establish a bar that is high enough that only the most determined spammer would bother.



I'm an avid bitcoin user, I pay for stuff in bitcoin whereever I can. But even I can't be bothered to keep funds in a hot wallet so I can make micro payments to sign up for forums. I don't expect you'll get many takers for that one :)


I advocate simply that you give them one tool to do this: BitID uniqueness weighting. (grasping for a good descriptive term here!)

The more aged coins this BitID user controls, the more likely they are to be a unique person. It's just a weighting - let site operators make use of it any way they wish.

For practical purposes, users will sign in with BitID using their wallet (the need of downloading a specific app defeats the purpose of easy integration). Therefore, if you want to show a proof of stake to the service, you'll need to have the private key on your wallet. So you can't use a cold wallet (by definition it's not cold anymore as soon as the private key is leaked anywhere).

The proof of stake has to be done by the server, which means the BitID server library will have to either integrate a full Bitcoin node, either use an API such as blockchain.info to get all needed information. This cannot be done by the wallet, as the service can't trust it (you could fork a wallet and patch it to send whatever proof of stake you want).

I like the idea of proof of stake as a spam fighting technique ; it could be quite effective.
I'll think about how I could integrate a first version in the BitID ruby gem. I'm just not sure if proof of stake could be computed from the blockchain.info API.

Eric

Please don't use a proof-of-stake system to 'trust' users like one of the previous respondents suggested.

Think about it on a fundamental level - he's asking you to trust wealthier people, or people who haven't touched their savings in a long time, more than the average user. This is just wrong.

Well, for me, the important question is not when was the last time I typed personal data on a website but how many times I did it. And the answer is far too many.  ;)

But you've got my point ! For transactions with e-merchants, I see BitId as a great way to prove that I own the rights to do (get, check, ...) something because there's a validated transaction and I can prove that I own a private key associated to an input address without leaking any other personal data. In this schema, an input address is like a token of ownership for a digital (or physical) good and BitId allows the exchange of this token in a very easy way.

My take is that in real life, most of the time we buy things without having to leak personal data and it should be the same in the digital world. I'm one of those guys who think that we've, far too much, let e-giants gather our personal data without even discussing about the value of these data and the services they provide (basic principle of a free market). But well, this is another discussion...  ::)
So, I wouldn't say this use case is tangential (I hope paiement of goods with bitcoin will become more and more mainstream) but I agree to say it's the easiest one to solve.

On its side, your schema seems interesting for the very different use case of forums / community websites which is more related to addresses as tokens for identities. It creates a very strong constraint with the age of bitcoins but as you wrote this constraint is the incentive to play fair. That's ok. My main question about this system would be : Do I have the same pressure/constraint if I'm a "rich" user (with lot of bitcoins in many addresses) or if I just have a few bitcoins ? To state it differently: Does user's stake really prove the goodwill to play fair ? I don't know the answer.

Imho, BitId should stay at a low level and provide generic implementations allowing exchange of tokens (signatures) between the user and the website. The fact that we imagine so different (but legitimate) use cases is for me a good indication that websites should be free to choose or implement the solution that best fit their needs to validate that a user creating an account is not a rogue player.

Anyway, it's nice to discuss these different schemes and how something like bitcoin and bitid could improve the actual systems.
My two bits.

All blockchain based spam prevention ideas I have seen are based on the necessity to spend some amount in order to get full access to services.
So yes, wealthy people could spam more, but this is a fact of life.

It's not about saying that money equals trust, it's about adding cost to abuse.

Negative. You only need a /signature/, created once by the key with access to the funds, which does not change. For an entirely manual implementation you could simply save the signature in a text file on your desktop and cut/paste it into a form on the website the first time you log in.

Try this:
1. Open bitcoin-qt
2. File -> Sign Message
3. Pick address that contains some aged funds
4. Enter message - "My BitID is: QRSTUVWXYZ"
5. Sign
6. Copy/paste the address and the signature into a text file (eg. "IAV7hQhB5d5z0PGJFpqF+xiGt1T+u6etvBx56jCA2TxXf9LaTb/+iX9H/87UKx9S9vOqiL11n1GqkoaTiGjsQwA=")
7. GOTO step 1, repeat for as many addresses as you desire

Now, if you happen sign into my website with BitID QRSTUVWXYZ, you need only provide me the contents of your static text file sometime (and only the first time you sign in) in order to establish that you're "probably genuine."

I determine how much weight I give to your genuineness based on the sum of (coins * age) in all the addresses you've provided that:
1. have correct signatures matching your BitID
2. I haven't yet blacklisted for being associated with bad behaviour

A higher weighting might mean you start with more forum reputation, or aren't challenged with a CAPTCHA. A low enough weighting means you still get the CAPTCHA / default newbie reputation / whatever (ie. status quo, no disadvantage.)



Indeed. There /is/ a little bit of extra work for the server here. But this is for a non-critical bitcoin application (no money gets lost if we screw up) so we don't need to run a full trustless node. A light SPV client like bitcoinj should work fine, or perhaps even something like the blockchain.io API. Hardly prohibitive resource-wise.


I think it'd be a nicer user experience if this were integrated with BitID, as the user could just configure their proof-of-stake signatures once and then not care, and get the free reputation benefit everywhere they use BitID. But, in the simplest case, as I say, a website that already accepts BitID login could just provide a "paste your proof-of-stake signatures here" text field for the user to optionally submit.

I'm just throwing ideas around here, but I suspect this could prove to be quite effective.

I'm not suggesting that wealthy people are intrinsically more trustworthy. Indeed, the weighting I'm talking about is not a measure of trust. It's just a measure of how likely any given user is not to be using a throwaway account.

When users are anonymous and accounts are free to create there is zero barrier to people creating hundreds of throwaway accounts, which has wreaked all kinds of havoc all over the 'net, and is mainly responsible for the current state of affairs of semi-illegible CAPTCHAs everywhere you look.

We're not trying to compare two genuine users, Alice and Bob, and determine that Alice is more trustworthy or important based on the fact she is richer. We're just trying to screen out the thousand spam accounts that Eve has created to try to game the ratings system / act as sockpuppets / troll their merry way around the ban-hammer. Above a fairly low bar everybody would be equal.

Eve's spam accounts will find it much harder to each reach that bar, because she has lots of them that she needs to fund. And every time an admin brings down the ban-hammer Eve suffers a setback.

Any genuine users who can't reach the bar will be indistinguishable from Eve, and will have to establish their reputation from scratch. But they currently do anyway. That's the current status-quo.

In reality showing that you had $20 sitting in one place for a month might be enough to skip the CAPTCHA on most sites. Or showing that you had ~$500 sitting in one place for a day, if you're wealthy and in a hurry. Or showing that you had ~$3 sitting in one place for 6 months, if you're really poor but not in a hurry. This is a mechanism that everybody can take advantage of to distinguish themselves from Eve's throwaway accounts, if they want to.

We can't prove goodwill, only "likelihood that user is not a throwaway account." But if you don't act with goodwill we'll ban your account (as per usual) and you'll be on to creating throwaway accounts soon enough. If you have a huge stack of bitcoins, and you're prepared to split them up into lots of addresses and wait for them to age... then yes, you could create a greater number of throwaway accounts that we erroneously think are legitimate users. But you'll still burn through them eventually :-)

Additionally, I'd suggest:
* you would have to be a very determined troll to plan your trolling weeks or months in advance :-)
* we could just "lift the bar" (adjust the weighting that our site is looking for upwards) so that your troll accounts still don't meet it

As you see, it's an arms race between you and the legitimate users. But you have two disadvantages:
* you have multiple IDs that you need to plan in advance and adequately fund (a normal user just has one)
* those multiple IDs that you put so much hard work into keep getting reset to zero every time you do something naughty with them

It isn't a perfect system. But it would surely discourage some (most?) trolls. It gives us the tools to fight, at least. Making life harder for trolls and scammers is IMO always worthwhile even if not perfect.

Just one other small point - it might be necessary to tweak the (balance * coin age) formula, perhaps to give more weight to balance, or more weight to coin age, or to impose a minimum coin age (1 day? 1 week?) or whatever.

I'm simplifying a bit here because I'm just trying to illustrate an idea.

The key point is that:
* BitID need not concern itself with the formula (but it would be helpful if it would automatically pass the address signatures (for proof of funds) during BitID login, to simplify the user experience.)
* Individual sites could employ a different formula to calculate the weighting (some might give more weight to coin age, some less) ... and use that weighting in different ways.
* What works best for any given site could be arrived at through trial and error.
* The user doesn't have to care. They just (optionally) provide signatures for a decent amount of funds that they've had lying in one place for a while, or intend to have lying in one place for a while, and forget about it. Anywhere it helps them with account creation (skip the CAPTCHA, start with +ve reputation, or whatever) is a bonus. Anywhere it doesn't (ie. 99% of the web) doesn't matter, no harm done.

If this were implemented I'd probably just put ~$100 into a new cold storage address, create my BitID signature, and then forget about it. As time goes on my ID will just continue to accumulate more and more legitimacy. I know I won't move it, so it doesn't have to be a huge amount (and, indeed, I'd refrain from signing with my main savings wallet, for financial privacy reasons.) If I ever need that $100 back it's still mine, so no harm (although my BitID's legitimacy rating would be reset as soon as I moved it, of course - but I could substitute/add other signatures at any time.)

100% agree with this

@gacrux: 2 questions:
- Am I right if I say that in this system, stake is validated only one time when creating the account ?
- Who generates what you've called the BitId QRSTUVWXYZ (user or website) ?

The idea sounds interesting to :
- avoid spammers using a massive number of addresses / private keys created on the fly to flood the forum
- "raise the cost" of trolling

I guess the "wealth issue" can be solved by choosing the "right" threshold: high enough to fight spammers/trolls and low enough to allow participation of everybody. So, the question seems to be: can we find such a threshold ?

Technically speaking, I envisioned a new challenge for each sign in (so it requires a new signature by the user) but I can imagine websites implementing something like what you've described which is very closed to a classic login/password authentication (address + challenge = login, signature = password).

Btw, this idea of mixing coins and age of coins makes me think to the movie "In Time" (synopsis: time is the new wealth). Do you know it ?

Edit: Cross-post. You've already answered some of my question in your last post.  :)

Your focus on preventing zero-day abuse shows you're really thinking of it as a chat forum tool. This is not the only potential usage case for BitID.

BitID is a highly secure, portable, widespread and free-to-use method of digital ID that can be used by anyone with a single Satoshi to their name.

If all you care about is stopping idiots on chat forums telling you how often they've fucked your mum, you're seriously overlooking the potentially revolutionary aspects of this ID technology.

Allowing it to remain a cheap, distributed single-point of access to any and all digital services will attract newcomers and allow the technology to bloom in ways you can't yet imagine.

Locking it down to people with masses of bitcoins to their name or people who were early adopters will see it fail like all other digital ID systems have.

Why does my webmail need to know that I'm 'more trustworthy'? Why does Netflix? Why would my phone?

It's your choice. Looking to create a 'trust' system based on value (age or amount of bitcoins at an address) is really premature for a technology which hasn't even launched yet.

It could be validated as frequently as the server needs. If the server just needs to decide whether or not to show you a CAPTCHA upon account creation (a very common use case I forsee) then once is fine. But if the server is doing something more complex there's no reason it couldn't refresh your stake weighting at will.


Uh, that's your BitID. (ie. the address you're using to sign in with BitID - replace QRSTUVWXYZ with your actual address.)

An email address would work equally well. We just need a way of tying the signature to your identity, so that nobody else can use it (and potentially get it blacklisted.) Anything unique that the website knows about you would work. But it's a hassle for the user to have to create the signatures more than once, so best to use something common (thus I thought it might be a good fit to use BitID.)


Well, everybody can always participate, exactly as they do now all over the web. Without a signature to prove ownership of a single satoshi you'd just be a normal user (ie. the status quo today.) Any threshold is better than nothing; there are only advantages to implementing this that I can see.


You have badly misunderstood me :-)

* This is not an authentication mechanism
* Authentication would happen with ordinary BitID (ie. signed challenge - no change there at all)
* In addition, once the user has successfully authenticated as per normal, the server can be optionally be given one or more signatures proving ownership of stake. The server can make use of the weighting it calculates from this information in any way it sees fit.
* The signatures are static because they just sign the user's ID (eg. BitID, or email address) - so they must be created exactly once and never change
* The server just used the signature to prove a link between the stake and the user, nothing else.

That was just one example.

I'm sure there are hundreds of use cases for BitID. And a single user can cheaply create hundreds of BitIDs for any of those use cases :-) How many of those use cases would benefit from being able to distinguish cheaply created throwaway BitIDs from more long-lived ones? Use your imagination.


Or even by anyone with zero satoshi to their name, right?

My proposal doesn't affect that in the slightest. Signatures proving stake are an optional extra for any user who wishes to provide them. Not doing so just means you get treated as a normal user (ie. the status quo today.)


Why should it not be cheap? It should be free.

Nobody is forcing anybody to prove stake if they don't want to.


Nobody suggested locking down anything. I'm afraid you must have misunderstood me somewhere.


Not a trust system.

gacrux - who are you exactly to speak with such authority about this project?

I'm here to simply offer suggestions and trying to frame the issues surrounding this novel ID method.

You're speaking from a presumed position of authority, defining with certainty about what this is and is not.

@NanoAkron I speak with no authority at all on BitID. In fact, I have nothing to say on what BitID is, what BitID is not, or what BitID should be. I sincerely apologise if I've given any impression to the contrary.

Please re-read my posts. I'm simply trying to illustrate a new idea here, which BitID may or may not benefit from incorporating, and which people implementing BitID are free to use or ignore as they see fit.

I speak with certainty only about my own proposal. I think you'll agree it's fair for me to be certain about my own ideas at least ;-)

The idea I'm trying to illustrate is just:
* there exists a way that anonymous users can offer information to a webserver that can help it distinguish them from throwaway accounts.

That is all. This idea exists independently of BitID, and could be implemented independently of BitID. It just makes it easier if the user has some sort of portable identity that they can tie the proof-of-stake to, so that they don't need to re-calculate it for every site. An email address would work fine.

I proposed the idea in this thread because:
* a BitID would also work fine (being a portable ID that could be used on multiple websites)
* the set of potential BitID users and the set of potential users of my proposal heavily overlap: all Bitcoin users, basically. That makes BitID an obviously natural fit.
* it would provide an additional benefit to use of BitID, potentially increasing adoption.

The two complement each other.

I've just pushed a new version of the python library on github : https://github.com/LaurentMT/pybitid
This version removes the dependency on an external library for all bitcoin and crypto stuffs. It embeds now a subset of V.Buterin's pybitcointools lib, adapted for compatibility with python 3.3.

Moreover, I've pushed a new demo app : https://github.com/LaurentMT/pybitid_2fa_demo
This toy project illustrates how bitid can be used to provide 2-Factor Authentication.

The initial demo app (simple authentication with bitid) can still be found at https://github.com/LaurentMT/pybitid_demo

Still a work in progress with many things on the todo list but all feedbacks are welcome !

I think I get the idea now.  ::)
The proof of stake is embedded in response provided by the user in order to "prove" her reputation. It would be an additional (and optional) information which can be provided via bitid protocol. In a way, I think that's very close of Eric's idea about metadata sent via bitid (see chapter "scope & permissions" in https://github.com/bitid/bitid/blob/master/bitid_metadata.md).

BitID has now a Javscript implementation :
https://github.com/porkchop/bitid-js

I don't know if this has been posted before but BitID is on CoinDesk: Authentication Protocol BitID Lets Users ‘Connect with Bitcoin’ (http://www.coindesk.com/authentication-protocol-bitid-lets-users-connect-bitcoin/)

This is an interesting project and I think there have been a lot of good comments on development side.

The question as some others have noted is "What is the specific need?" 

We have OpenID and many other authentication systems used by websites today so what are the core advantages to this?

OpenID, Connect with Facebook and all those other systems leak personal information to a website. BitID limits it to a Bitcoin address (which you don't have to use). That is one of it's biggest advantages if you ask me.

Correct me if I am wrong EricKennedy

Let's have a thought experiment: After a long week, you decide to have some fun and go to the movie theater.
You: Hi ! May I have 2 seats for the wolf of wall street ?
Cashier: Sure ! May you fill this form with your civility, firstname, lastname, address, phone number, credit card number, expiry date and CVV2 ?
You: ...
Cashier: ...?
You: wtf ?!!!

In real life, payment is the only thing required to finalize a transaction with a merchant. Sometimes it makes sense to disclose personal data but these cases are exceptions (when you expect a delivery, when you rent an expensive good, ...). In the digital world, disclosing personal data to access bought goods or services has always been the rule but this model has several drawbacks:
- it's conceptually wrong: it introduces the concept of identity in processes which should not rely on identity,
- it requires customers give personal information without any additional gain for them,
- it requires e-merchants act as secure data hosts, when their core business is selling products or services,
- it frequently results in data leaks producing nuisances like hacked accounts, phishing, spam,...

BitId protocol (associated to bitcoin and payment protocols) can be used to improve the current model existing in the digital world.
Imho, its main strengths are:
- a very good UX (as stated by @EricKennedy "BitId is 80% UX and 20% code"),
- users just have to secure one "database" (their bitcoin wallet),
- BitId and Bitcoin protocols are built on the same crypto stack (ecdsa, secp256k1, ...). All efforts done to detect potential flaws in this stack for Bitcoin will profit to BitId.

And of course, this is just one use case. Many others can be imagined...

https://nameid.org has done this for a while with Namecoin, there's php source code for it & a firefox plugin. Try to make your implementation fairly closely compatible if possible.

NameID is about storing your identity into Namecoin, BitID is about authenticating to a service by proving you control a Bitcoin address.

BitID and NameID complement themselves.

For instance :
1. you sign in on a service with your BTC address using BitID
2. the service queries NameID and retrieves the identity (name, email, avatar...) attached to this address

Here is one implementation of a simple BitID client in Python :
https://github.com/antonio-fr/SimpleBitID

You can install it on windows (.exe in release section), MacOS or Linux and test the user flow with the demo service :
http://bitid.bitcoin.blue

Glad to see so much progress. You are doing a great job dude. Keep it up :)

The site http://txid.co start support BitId login now!
Its a bitcoin news aggregate site for chinese peoples.

That is amazing news. I am so happy that this project is moving forward!

libpam-bitid: A PAM module to use a bitcoin address for credentials.

This is a linux PAM implementation of the BitID protocol. Linux system access is granted using just a bitcoin address.

It currently supports pam.d configuration for console or telnet login.

Github: https://github.com/angrycod/libpam-bitid

Example output:

Thanks to manuelzs (https://github.com/manuelzs), django developers can now play with BitId (Github (https://github.com/manuelzs/django-bitid/) - Pypy (https://pypi.python.org/pypi/django-bitid/0.1))

Chiming in:

This particular protocol is the best to happen to usable security in a very, very long time.

This simple protocol extension offers two-factor authentication at higher usability and security than a one-factor login/password combo.

Assuming most people have some sort of screen lock on their phones, this provides for a two-factor authentication at the ease of pointing your phone at the screen. Bravo! Applause!

I actually wanted to start implementing this protocol server-side today, and was surprised to see that my Android wallet didn't yet have support for it.

I can't wait to offer something as simple and secure as this to users of my systems.

Cheers,
Rick

Right now, there is only a fork of Android Bitcoin Wallet supporting BitID
https://github.com/bitid/bitcoin-wallet

We need to finish it (missing some UI touch), and then submit a pull request to hopefully have it integrated into the main client.
The problem is I don't have much time right now :) I wish I could find another Android coder to help me.

Eric

Source: Google+ Beta Tester Group (https://plus.google.com/u/0/+AndreasPetersson/posts/giGLijXWfcQ?cfem=1)

Going good Eric ;D

BitAuth (http://blog.bitpay.com/2014/07/01/bitauth-for-decentralized-authentication.html) seems to look a lot like BitID or am I just plain stupid?

;D
Main difference seems to be in nonce generation (client-side for BitAuth) but I'm not fond of this choice.

Edit: Another difference is that each request to the server is signed by BitAuth. I like the idea even if signing all requests may be a bit overkill. It also explains why the nonce is generated client-side.

Are there any best practice proposals to decide which key to use to sign?
Like using my HD master private key, appending the hostname, hashing, and using that as new private key for signing in?
Using the same mechanism for identity management would allow users to use their identity from within different wallets which have the same key / seed.

Right now best practice is to generate arbitrary key from a domain and save it into a local db.
It could indeed be replaced by hashing an HD master key with the domain name, thus avoiding the need of such db.

Sorry, but NameID does both, you're repeating work. You can log in using NameID to prove you own the Namecoin address linked to your Namecoin ID information. That's how it has worked for a while.

You're right but there's an important difference between NameId and BitID:

• NameID relies on OpenID which is a nice system but requires a third-party (the identity provider) to let you authenticate.
• With BitID, no third-party is required. It's just your wallet and the website.

Both systems have their strengths and their weaknesses. It's a matter of choice.

i think it will automatically when evertime connect and some defense for big bucks in cold walletthats important to . to save money in the right place

This is awesome, great work.

I'm really happy to see this. I came up with a similar idea on my own and am planning to implement it in a project I am working on. The fact that some of the work has already been done for me is terrific.  ;D

Can someone please explain why SQRL was not sufficient, and what BitID fixes over that?

SQRL and BitID, are basically the same thing, just one uses bitcoin addresses. Also since bitcoin addresses are becoming more ubiquitous it would be a better way.

Technically we could also ask the question why not use PGP keys?

BitID is SQRL scoped to the Bitcoin realms.
The main advantage is that if all wallets implement BitID then everyone will benefit of the possibility to sign in with their address.

Then how come people on the Internet's are saying that SQRL is superior to BitID, and BitID has some bugs, security issues, or shortcomings that SQRL does not?

It doesn't make a lot of sense to compare SQRL and BitID in terms of who is superior to whom. Outside of Bitcoin realm, BitID doesn't make any sense ; so yes you could say that SQRL is "better".

Anyway BitID is not trying at all to compete with SQRL.

About security issue, I guess they are the same than SQRL (middle man attack). I'd be glad to answer more precisely on specific questions.

Sorry, I meant, could someone explain why we couldn't just implement SQRL itself with bitcoin keys, and needed to come up with something different like BitID?

People like to say that nobody should reinvent the wheel and that one should support the existence of standard protocols. That's without any doubt a good engineering principle. I agree with that. The problem is that it's a pure technical vision of things which doesn't take into account incentives provided by a technology. As far as I know, Eric never claimed that he had invented a new authentication schema. He has come up with a damn simple protocol and a nice implementation which offer strong incentives to integrate this schema in consumers product (wallets, websites, ...).

It's not a secret that our digital life is filled of kinks (see "Motivation" chapter in this document (https://github.com/bitid/bitid/blob/master/bip70_extension.md)) even if:
- technologies allowing "anonymous" authentication with public/private keys exist for decades
- PGP exists for decades
- SQRL exists for almost one year

After its announcement, in less than 3 months:
- BitId is supported by different languages and platforms (cms, wikis, ...) thanks to independant devs who spent a little time to develop libs and plugins
- some people (who are not devs) start to offer bounties (https://coinality.com/jobs/bitid-authentication-for-joomla-2-5-odesk/) to have bitid integrated in their favorite tools
- BitId has started to been integrated in "consumer products" (dark wallet, mycelium)
- BitPay has open sourced its own version of a similar schema after announcements by dark wallet and mycelium

This was made possible because BitId offers strong incentives to developers:
- it's easy and fast to integrate in existing products
- it relies on the crypto stack already used by bitcoin
- efforts done to secure the coins also secure the authentication keys
- security can be easily reviewed
- It's an open protocol. Everybody is welcome to participate

At the end, the important point is not which protocol is used but the fact that people can experiment by themselves that digital life is not doomed to be a perpetual privacy leak. And the more people experiment this reality, the more developers will be incentivized to expand BitId or integrate others protocols like SQRL in their products.

IMHO, the most important strength of BitId is that it provides the needed incentive to initiate the "avalanche".

On the technical side, here are a few points:

• internet is full of people who like to criticize ideas. Critics are good and necessary. But always ask them this simple question : did you read specifications, source code of the thing you criticize ?
• all things which can be done by SQRL can be done by BitId
• BitId is versatile:
  
  • you can generate keys for each website/system you want to sign and get "anonymous" authentication
  • you could use future systems like SINs which establish your online identity and sign in with this unique identity
  • as proposed by some people in this thread, you could link authentication rights with some bitcoin address used for a transaction or owning some coins. Basically, your authentication rights are linked to a proof of stake or a proof of payment. Definitely something which can't be achieved with SQRL

No, you're still misunderstanding, nameid.org just uses openid as an example, it doesn't rely on openid at all, it relies on Namecoin ID. The php source code for nameid.org is open, you could use that auth mechanism on your own website as is, without openid, or reimplement it in another language. It sends a message, you sign it with the key used for your namecoin id, the site checks the signature & logs you in. It works almost exactly like BitID, but pre-dates it & allows you to link it to your ID information stored in Namecoin.

Hi wbaw,

I fear I can't agree with you on that point. OpenID is not just an example used by NameID. It's a core component of its concept. That's clearly stated in the FAQ (https://nameid.org/?view=faq) and on the homepage (https://nameid.org/)

If you remove OpenID from NameID, it's no longer NameID.


Agree. NameId uses a principle of digital signature like BitID, Bitcoin and many systems before. But it isn't the core value of NameID. The true value of NameID is that it integrates Namecoin and OpenID.


Agree !

Tell me if I'm wrong but I feel that your main interest is not in OpenID but in being able to use a Namecoin ID to sign in.
For now, BitId only supports bitcoin address format (1....) but it would be easy to extend this behaviour to manage additional formats like Namecoin addresses (N...) or SIN (https://en.bitcoin.it/wiki/Identity_protocol_v1) addresses.

I think that supporting different address formats is a natural evolution of BitID because there's legit use cases for people wanting to sign in with a unique public identity managed by Namecoin or by a SIN. That sounds to me like a natural complement to the existing behaviour allowing to sign in with bitcoin addresses or "ephemeral ids" (when you want to keep some privacy).

I don't know if Eric and others devs share this vision but if you're interested by the addition of Namecoin ids in BitId, I encourage you to open an issue on github (https://github.com/bitid/bitid). I'll be pleased to support your request !

I really really REALLY want to launch this as the preferred authentication method for a project I'm developing. The ease-of-use is positively outstanding, and in particular, the lack of need to install Yet Another App as it just piggybacks on the bitcoin wallet. Do we have any idea (best wild-ass guess) when bitID may be available in the mainline Android client, something even marginally better than "between yesterday and in two forevers"?

Cheers,
Rick

(I'm assuming here that the Android Wallet fork makes use of the fact that the Android wallet already has an address selection mechanism on the home screen, so it's literally just point-and-you're done for authentication; no need to confirm or select signing address?)

The fork of Android Wallet including BitID is not good for release ; it still requires some tests and UI enhancements. Not a lot of work (few hours I guess), but right now I don't have the time.

It is indeed point and confirm for first time; and next time it will auto confirm. No need to select and address, it will be created on the spot.

For a more complete version including metadatas, it would require a few days of work.

I hope to have an Android engineer working on this release beginning of September. If not then I'll set up a bounty to have the work done.

I see the privacy gains of not using an existing bitcoin address for authentication.

Will the private keys of this address also be backed up along with the wallet addresses? If not, then some recovery mechanisms will be necessary app-side. I guess that's necessary anyway.

As long as primary UX is point-and-logged-in (no more steps than enabling camera and pointing it at screen), I'm happy. Once this UX is good enough, what are the prospects of getting into the mainline Android client?

Cheers,
Rick

In the case of Mycelium, we have a working demo in our dev build, but we are going to hold off until we get HD wallets finished. Reason is that without, your BitID will only be tied to a single address, and with HD you will be able to have a different ID for different sites, all coming from the same seed used for your bitcoin addresses.

Hi there,

I've just pushed a new version (r0.0.3) of the python library on github (https://github.com/LaurentMT/pybitid):
- Fixed a problem with urlparse in python 2.7
- Cleaned package structure
- Created a setup script for clean installation (setuptools)

I've also setup a demo server with 2 python demos (authentications with mainnet addresses):
- BitId authentication demo : http://vps90685.ovh.net:8080/ (http://vps90685.ovh.net:8080/)
- BitId 2FA demo : http://vps90685.ovh.net:8081/ (http://vps90685.ovh.net:8081/)

EDIT:
BitId authentication demo with testnet addresses: http://vps90685.ovh.net:8084/ (http://vps90685.ovh.net:8084/)

A combination of this and onename.io would be great

Does BitID support multi-sig? Using SigSafe and a smartphone multi-sig private key would be cool for signing on to websites!

Hi, I'm working on an android app at the moment. I can log onto erics implementation (ruby on rails app) but not yours.

I think this may be a confusion over the protocol. I'm posting the following parameters.

OK. I've deployed the latest onchain.io app with Bit ID support to the play store.
https://play.google.com/store/apps/details?id=stamp.app&hl=en

Github repository. https://github.com/onchain/onchain-android

I still have the issue above but it will have to wait.  If anyone has some feedback for me on this, that would be great.

Hi onchain !

Sorry for the late answer (was out of office).

Regarding the structure of your request, everything seems ok.
I assume the values are those used with the rails demo and that you had different uri, signature & address for your test with the python demo. That's right ?
May you check the value of the field "message" in the json returned by the server ? It should give us a first hint about the problem.

That's correct.


I'll do some extra debug now. Thanks.

OK, thanks. Seems to be working now.

https://i.imgur.com/NLpfdyM.png
https://i.imgur.com/5sgvJqy.png

I've just done a quick check with the values sent in your previous post. At library level all tests (bitid uri, address, signature) are ok. I guess the problem is with the app demo or with the server. The /callback POST request has a mimetype header set to "application/json" ?

EDIT :
Ooops. Cross-post :)
Cool ! What was the problem ?

Not sure. It's working now, that's the main thing. :)

Sure. Anyway, it's really great that you've integrated Bitid in the wallet !
Unfortunately, I don't own an android smartphone, so I won't be able to check your android app against futures version of the library but if your web web wallet manages bitid, I'll add it to my list of test platforms with Dark Wallet.
Keep up the good work !
Laurent

Dark Wallet supports BitID ? Do you have a link I can look at.

They do, since their last release (alpha 5 (https://wiki.unsystem.net/en/index.php/DarkWallet/Alpha5))

I can confirm the demo on http://vps90685.ovh.net:8080/ works with mycelium wallet, too.
Mycelium warns me about the callback using http instead of https, though :)

(Also, mycelium will not have bitid for prodnet right away. The prototype implementation is just available in the last regular testnet build, and for HD will be working again in the next alpha release on testnet, allowing you to have multiple bitid identities, one for each HD account (or single address account))

Thanks for the feedback and information !
The warning about http instead of https is a great idea. All websites should use https  ::)

I was just about to post that too. Really cool!

how did you do it? i am unable to get it work with my mycelium wallet.
is there a list of android apps which are supporting BitID?

BitId is currently only enabled in the testnet version of mycelium.
We are still discussing whether we want to derive the keys in the exact way we do now.
Note that the example listed above will reject testnet addresses as invalid, in order to test that one I enabled bitid for my prodnet version.

That's right, http://vps90685.ovh.net:8080/ is setup to reject all addresses which are not mainnet addresses.
Here is a new instance of the demo app for testnet addresses: http://vps90685.ovh.net:8084/

I just tried the TestNet version and I can confirm that it works like it should. Thanks for keeping those servers up and running. ;)

I intend to implement this as a 2FA sign-on in Swarmops over the next two weeks. I've never seen _anything_ matching its ease of use.

Is there redistributable server-side code somewhere I can use as a template? My platform is ASP.Net and C#. I would rather not reimplement crypto code, but I am happy to change its syntax keywords from another implementation language.

Cheers,
Rick


(Swarmops: https://github.com/Swarmops/Swarmops)

Thumbs up here too.

Hi Falkvinge,

There's no server-side code written in C# yet but it would be really great if someone can achieve that.

WRT crypto code, there's a great bitcoin library written in C# : NBitcoin (https://github.com/NicolasDorier/NBitcoin)
I'm almost sure that you can get all the crypto code required by BitId (basically the verification of ECDSA signatures) from this library.
You may contact Nicolas Dorier (maintener of NBitcoin) to check if you can reuse parts of his code and where to find the relevant code.

WRT BitId code, implementing server-side code is quite straightforward. There's several implementations in different languages :
- Ruby (https://github.com/bitid/bitid-ruby) (original code)
- Python (https://github.com/LaurentMT/pybitid)
- JS (https://github.com/porkchop/bitid-js)
- PHP (https://github.com/conejoninja/bitid-php)

I hope it helps. Do not hesitate if you need more details about the protocol.


You're welcome  :)

Some feedback - this part was not clear to me:


Specifically, in what standard format are the parameters passed? Using Json? Http headers? Encoded onto the Uri? What? A tangible example of the exact HTTP POST request sent from the client, byte by byte, would have been enormously helpful here. As is now, I'm blind on the server side - I don't know what data to expect and have to guess how the client sends its data?

I had also considered this exact idea (being a fan of QR codes) - IMO the main thing to really help this to happen would be the software to be available for smart phones and a smart phone that can be *permanently disconnected from all normal comms*.

I have read about (more or less) transparent Faraday cages so I am thinking that an inexpensive approach might be to use an old smartphone and such a Faraday cage to create an authenticator that never needs to be online.

I don't get it... How should me phone authenticate me to some server without contacting that server?

It's really quite simple - to "sign up" your phone creates a public key that it displays as a QR code and you use the camera on your PC to *scan it*. Then it sends back a public key (for your account) along with a one time message as a QR code that you then scan with your phone. Your phone then *signs a message* with its private key for the public key (and the one time message) and displays that as a QR code - you now again show your phone to the camera and you are done.

When signing in at a later stage you first enter your username - it will then display a QR code that is the public key and one time message. You scan this with your phone and then it creates a QR code of the *signed response" which lets you "log in".

So your phone never needs internet access to do this (just needs a camera and a display).

It is not that much more difficult than a traditional login (especially if you consider 2FA) and it is 100% secure (getting people used to this idea is going to be the hardest part).

This makes the whole process more cumbersome plus forces me to have an offline phone just for signing in. People willing to take these hurdles could as well use a dedicated hardware device or some of the long available complicated options for secure authentication.
The beauty of bitid is that it requires only a mobile wallet and a very simple step. It's easy and get it for free if you use a mobile wallet anyway.

You could of course proxy the callback with some software reading from a QR code on the phone. But, you know, complicated more secure systems which don't get used improve  security less than systems which get used cause they are easy and still a hell lot better than this username  plus password crap we have today.

If you go here :
http://bitid.bitcoin.blue/login
And click on "manual", you'll get a curl example showing exactly how to POST on the demo server implementation.

Thanks, but that's not what I need. I'm trying to write a server-side implementation. I need to know what the client is sending to me, and to be honest, that's not specified. I'm in the blind. I'm trying to use a BitID client and just see whatever it is sending by pushing debug code out to production (accessible) servers. That's not how any development should be done but I'm given no choice right now.

In a spec, I'm expecting, and asking for something like this:

SAMPLE CLIENT LOGIN REQUEST


SAMPLE SERVER RESPONSE


Do you see where I'm coming from? It just says that four specific parameters are submitted as part of an HTTP POST. It doesn't say anywhere how those four parameters are encapsulated and encoded. I need to know that in order to implement this. (In this example, I wrote the spec part as if they were submitted using Json, which I don't think they are, but you get the point.)

Cheers,
Rick

Here's my notes, written while working on the python library. Hope it helps.

Thanks, it does! I found at least one reason my server doesn't pick up the response.


Does it have to be this (partial) URI, or is it just a header describing this section? That's unclear. I have been using a different URI, as I'm using the [WebMethod] feature of Asp.Net that lets you embed a Json-callable function on any page.


Can we lock down that the parameters come IN THIS ORDER? That's not explicitly written, and some implementations (like C# which I'm using) are or can be order-sensitive, even with parameter names supplied.

Testing again now.

Cheers,
Rick

Sorry for the late answer. Was musing in the french subforum  ::)

The uris "/callback" can be something else. The client should only rely on what it has received in the bitid_uri.
I think we've all followed a kind of implicit norm by reusing the same "/callback" uri but the protocol does not state any such rule.
EDIT: Here is an example of a different callback uri used in my 2FA demo (http://vps90685.ovh.net:8081/) (uses a "/tfa_activation_callback" uri)

Ooops. That sounds like a more serious issue.
On its side, BitID protocol does not state any specific order for the parameters.
Main problem is that such a rule would have a direct impact for wallets developers.
Thus, I think it's better if Eric answers this point.

I may be wrong but to my knowledge, there's no notion of order in json. A lib forcing an order for json content seems to me like a bad implementation of json.

Ok, now I know exactly what the HTTP request from Onchain looks like (which works against the BitID demo). No wonder I couldn't get it to work. The phone app doesn't use Json at all, but does a full webform post.

This is what I was asking for in the spec as a sample:


And here I was trying to interpret Json and wonder why the server did absolutely nothing... :)

I would agree with this and I'm not certain this is even the case. I'm on a wild goose chase for bugs at this point to find out why my implementation isn't responding.

Cheers,
Rick

This is big.

It is enabled in the mycelium testnet app, if you want to try. :)

Interesting. I thought that all wallets were using json format to send these parameters but it's true that it's not a requirement made by the protocol.

If you have some time, send me a PM with your comments/fixes about the draft in my previous post. I'll gather everything and send it to Eric to get something on github.


Arfff. I know this feeling when you spend time looking for the causes of a bug and finally notice that you didn't look at the right causes. I fear it's the curse of all developers.  ;)
By the way, it's great that you work on this integration of BitId with C#. It's a great platform and I expect we see more .NET bitcoin projects thanks to efforts like yours or NBitcoin.

Two things:

It works.

It's wonderful.

I love this. I'm logged in to Swarmops (my current project) before my phone has even confirmed it has transmitted the signed nonce. This is as smooth as Lastpass' autologins, except 2FA since it combines what you have with what you know (your phone's password, in this case).

If anybody wants to copy my C#/Asp.Net code, feel free. The relevant parts are easy to extract from Login and BitId here:
https://github.com/Swarmops/Swarmops/tree/master/Site5/Security

They may still be a little unstable with regards to threading on Mono (which sometimes cuts a request short and strange things like that), but the code works at a prototype level.

Cheers,
Rick

Not sure it will help with your issues but you may have to send additional headers to solve a problem specific to I.E. (I.E. caches XMLHttpRequest responses).
From my souvenirs, the problem was with the '/auth' call.

After a long fight, I managed to add QR code output and http callback to Jay's libpam-bitid. Now you can use your mobile phone to authenticate a ssh session. It works for sudo as well, and probably anything that can output the QR code into the terminal. It probably wouldn't work for a graphical session manager / screensaver.

You can find the fork at https://github.com/PeterSurda/libpam-bitid

Cheers,
Peter

I made a youtube video to show how cool it is: https://www.youtube.com/watch?v=U6I4HuzSTM0 (https://www.youtube.com/watch?v=U6I4HuzSTM0).

this is pretty cool.

Video is a bit of a problem for me - is there a written reference of what you did?

I typed "ssh localhost", it displayed a QR code and I used my phone (with skubit BitID client) to scan and authenticate it.

In the second attempt, I copy&pasted the BitID URL into a browser, replaced "bitid://" with "http://", the QR code showed in the browser instead of the terminal and I also scanned & authenticated.

Sorry the video is fuzzy.

Thanks - very interesting.

A oAuth bitId server would be nice to be able to integrate with existing apps who support oAuth without the need to learn another auth flow. Anybody working on this maybe?

Let's crowdfund one.

Ledger Wallet (http://"https://www.ledgerwallet.com") (hardware wallet) supports BitID.
Video demonstration here: https://www.youtube.com/watch?v=6vGxgLB6Y0w

Code is pretty straightforward:

nice ledgerwallet!