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

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

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  

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

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

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

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.

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.

fixed

yes you can connect with openid, check it out.


How do I sign into an OpenID-enabled site?

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


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


What do I need in order to use NameID?

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


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.

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)

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 is pretty awesome, OP. I like it.

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

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

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.

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.

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.

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.

I really like this idea!   

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