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

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 ?

OK, thanks. Seems to be working now.

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

That's correct.


I'll do some extra debug now. Thanks.

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.

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, 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.

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

A combination of this and onename.io would be great

Hi there,

I've just pushed a new version (r0.0.3) of the python library on github:
- 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/
- BitId 2FA demo : http://vps90685.ovh.net:8081/

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

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.

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

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'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?)

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

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 and on the homepage

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 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. I'll be pleased to support your request !

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.

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

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?

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.

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?