Bitcoin Forum
September 24, 2017, 09:27:23 PM *
News: Latest stable version of Bitcoin Core: 0.15.0.1  [Torrent]. (New!)
 
   Home   Help Search Donate Login Register  
Pages: 1 2 3 4 5 6 7 8 [All]
  Print  
Author Topic: [BIP][Draft] BitID - "Connect with Bitcoin" protocol  (Read 21688 times)
EricKennedy
Sr. Member
****
Offline Offline

Activity: 360

CEO, Ledger


View Profile WWW
April 04, 2014, 08:41:44 AM
 #1

Request for discussion

Code:
BIP: TBD
Title: Bitcoin address authentication protocol (BitID)
Author: Eric Larcheveque, @EricLarch
Status: Pre-draft
Type: Process
Created: TBD

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 :

Code:
bitid://www.site.com/callback?x=NONCE

  • 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



1506288443
Hero Member
*
Offline Offline

Posts: 1506288443

View Profile Personal Message (Offline)

Ignore
1506288443
Reply with quote  #2

1506288443
Report to moderator
1506288443
Hero Member
*
Offline Offline

Posts: 1506288443

View Profile Personal Message (Offline)

Ignore
1506288443
Reply with quote  #2

1506288443
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1506288443
Hero Member
*
Offline Offline

Posts: 1506288443

View Profile Personal Message (Offline)

Ignore
1506288443
Reply with quote  #2

1506288443
Report to moderator
1506288443
Hero Member
*
Offline Offline

Posts: 1506288443

View Profile Personal Message (Offline)

Ignore
1506288443
Reply with quote  #2

1506288443
Report to moderator
gweedo
Legendary
*
Offline Offline

Activity: 1246


Java, PHP, HTML/CSS Programmer for Hire!


View Profile WWW
April 04, 2014, 08:54:06 AM
 #2

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

To be honest this is too niche to be included in the bitcoin client at this time, and will probably be shot down. Instead just develop it on your own and convince people to put it into their wallet systems.

Want to earn 2500 SATOSHIS per hour? Come Chat and Chill in https://goseemybits.com/lobby
Mitchell
Staff
Legendary
*
Offline Offline

Activity: 1568


Verified awesomeness ✔


View Profile WWW
April 04, 2014, 08:55:19 AM
 #3

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.

          ▄█████▄
        ▄█████████▄
      ▄████▀   ▀████▄
    ▄████▀   ▄ ▄█▀████▄
  ▄████▀   ▄███▀   ▀████▄
▄████▀   ▄███▀   ▄   ▀████▄
█████   ███▀   ▄███   █████
▀████▄   ▀██▄▄███▀   ▄████▀
  ▀████▄   ▀███▀   ▄████▀
    ▀████▄       ▄████▀
      ▀████▄   ▄████▀
        ▀███  ████▀
          ▀█▄███▀
.
|
.
|
          ▄█████▄
        ▄█████████▄
      ▄████▀   ▀████▄
    ▄████▀   ▄ ▄█▀████▄
  ▄████▀   ▄███▀   ▀████▄
▄████▀   ▄███▀   ▄   ▀████▄
█████   ███▀   ▄███   █████
▀████▄   ▀██▄▄███▀   ▄████▀
  ▀████▄   ▀███▀   ▄████▀
    ▀████▄       ▄████▀
      ▀████▄   ▄████▀
        ▀███  ████▀
          ▀█▄███▀
unthy
EricKennedy
Sr. Member
****
Offline Offline

Activity: 360

CEO, Ledger


View Profile WWW
April 04, 2014, 10:04:20 AM
 #4

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

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.

To be honest this is too niche to be included in the bitcoin client at this time, and will probably be shot down. Instead just develop it on your own and convince people to put it into their wallet systems.

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

Jan
Legendary
*
Offline Offline

Activity: 1043



View Profile
April 04, 2014, 12:34:40 PM
 #5

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

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.


Mycelium let's you hold your private keys private.
instagibbs
Member
**
Offline Offline

Activity: 114


View Profile
April 04, 2014, 12:50:14 PM
 #6

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.
EricKennedy
Sr. Member
****
Offline Offline

Activity: 360

CEO, Ledger


View Profile WWW
April 04, 2014, 12:57:28 PM
 #7

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

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

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

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.

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

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.

The signature should contain the bitid URI, the nonce,  and be prefixed with"Bitcoin Signed Message:\n" like any other Bitcoin signed message

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.

Off the top of my head I would do it like this in Mycelium:
...

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.

Rassah
Legendary
*
Offline Offline

Activity: 1680


Director of Bitcoin100


View Profile
April 04, 2014, 02:06:35 PM
 #8

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

EricKennedy
Sr. Member
****
Offline Offline

Activity: 360

CEO, Ledger


View Profile WWW
April 04, 2014, 03:16:24 PM
 #9

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

Portnoy
Legendary
*
Offline Offline

Activity: 1974

My money; Our Bitcoin.


View Profile
April 04, 2014, 08:34:57 PM
 #10

I really like this idea!   Cool
Rassah
Legendary
*
Offline Offline

Activity: 1680


Director of Bitcoin100


View Profile
April 05, 2014, 06:38:32 AM
 #11

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

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.

benjyz
Full Member
***
Offline Offline

Activity: 140


View Profile
April 05, 2014, 01:50:19 PM
 #12

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.
Peter Todd
Legendary
*
expert
Offline Offline

Activity: 1106


View Profile
April 05, 2014, 02:03:15 PM
 #13

Peter Todd and Gregory Maxwell tend to argue for WoT

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.

Carlton Banks
Legendary
*
Offline Offline

Activity: 1764



View Profile
April 05, 2014, 03:31:43 PM
 #14

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.

Vires in numeris
Wolf0
Legendary
*
Online Online

Activity: 1694


Miner Developer


View Profile
April 06, 2014, 08:50:39 AM
 #15

This is pretty awesome, OP. I like it.

Code:
Donations: BTC: 1WoLFdwcfNEg64fTYsX1P25KUzzSjtEZC -- XMR: 45SLUTzk7UXYHmzJ7bFN6FPfzTusdUVAZjPRgmEDw7G3SeimWM2kCdnDQXwDBYGUWaBtZNgjYtEYA22aMQT4t8KfU3vHLHG
soullyG
Hero Member
*****
Offline Offline

Activity: 593


Decentralize everything


View Profile
April 08, 2014, 09:11:26 AM
 #16

Great idea - I look forward to hearing more about this in the future!
vane91
Member
**
Offline Offline

Activity: 95


View Profile
April 08, 2014, 09:39:55 AM
 #17

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

EricKennedy
Sr. Member
****
Offline Offline

Activity: 360

CEO, Ledger


View Profile WWW
April 08, 2014, 10:02:26 AM
 #18

you mean this:
nameid.org
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)

EricKennedy
Sr. Member
****
Offline Offline

Activity: 360

CEO, Ledger


View Profile WWW
April 08, 2014, 10:04:21 AM
 #19

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.

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)

renee25
Member
**
Offline Offline

Activity: 74


View Profile
April 10, 2014, 03:47:12 PM
 #20

you mean this:
nameid.org
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)


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.



Quote
there is not yet a wallet implementing this BIP.
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.

Don't donate me: donate to nmc re-base development project.
renee25
Member
**
Offline Offline

Activity: 74


View Profile
April 10, 2014, 05:54:02 PM
 #21


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


irony mode off


fixed

Don't donate me: donate to nmc re-base development project.
NanoAkron
Sr. Member
****
Offline Offline

Activity: 252


View Profile
April 10, 2014, 11:04:41 PM
 #22


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.


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.
schalk
Jr. Member
*
Offline Offline

Activity: 36


View Profile
April 11, 2014, 05:18:04 AM
 #23

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.
fbueller
Sr. Member
****
Offline Offline

Activity: 412


View Profile
April 11, 2014, 10:37:19 AM
 #24

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

Bitwasp Developer.
EricKennedy
Sr. Member
****
Offline Offline

Activity: 360

CEO, Ledger


View Profile WWW
April 16, 2014, 02:16:19 PM
 #25

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

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

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

The message to sign being for instance :

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

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

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

Eric

EricKennedy
Sr. Member
****
Offline Offline

Activity: 360

CEO, Ledger


View Profile WWW
April 17, 2014, 12:39:38 PM
 #26

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

btchip
Hero Member
*****
Offline Offline

Activity: 628

CTO, Ledger


View Profile WWW
April 18, 2014, 05:08:17 AM
 #27

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


The message to sign being for instance :

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


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

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

EricKennedy
Sr. Member
****
Offline Offline

Activity: 360

CEO, Ledger


View Profile WWW
April 18, 2014, 08:42:09 AM
 #28

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

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

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

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

Eric

EricKennedy
Sr. Member
****
Offline Offline

Activity: 360

CEO, Ledger


View Profile WWW
April 18, 2014, 10:58:31 AM
 #29

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

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

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

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

Thanks for clearing this mess Smiley

Eric

EricKennedy
Sr. Member
****
Offline Offline

Activity: 360

CEO, Ledger


View Profile WWW
April 20, 2014, 07:15:56 PM
 #30

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

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

Mitchell
Staff
Legendary
*
Offline Offline

Activity: 1568


Verified awesomeness ✔


View Profile WWW
April 20, 2014, 07:40:08 PM
 #31

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

          ▄█████▄
        ▄█████████▄
      ▄████▀   ▀████▄
    ▄████▀   ▄ ▄█▀████▄
  ▄████▀   ▄███▀   ▀████▄
▄████▀   ▄███▀   ▄   ▀████▄
█████   ███▀   ▄███   █████
▀████▄   ▀██▄▄███▀   ▄████▀
  ▀████▄   ▀███▀   ▄████▀
    ▀████▄       ▄████▀
      ▀████▄   ▄████▀
        ▀███  ████▀
          ▀█▄███▀
.
|
.
|
          ▄█████▄
        ▄█████████▄
      ▄████▀   ▀████▄
    ▄████▀   ▄ ▄█▀████▄
  ▄████▀   ▄███▀   ▀████▄
▄████▀   ▄███▀   ▄   ▀████▄
█████   ███▀   ▄███   █████
▀████▄   ▀██▄▄███▀   ▄████▀
  ▀████▄   ▀███▀   ▄████▀
    ▀████▄       ▄████▀
      ▀████▄   ▄████▀
        ▀███  ████▀
          ▀█▄███▀
unthy
NanoAkron
Sr. Member
****
Offline Offline

Activity: 252


View Profile
April 20, 2014, 07:42:05 PM
 #32

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

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

Very good demonstration of a very good idea.

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

Activity: 980


Monero Evangelist


View Profile WWW
April 20, 2014, 08:40:20 PM
 #33

Where is the problem for this solution?

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

Code your own tool/client/fork whatever IHMO.
marcus_of_augustus
Legendary
*
Offline Offline

Activity: 2380



View Profile
April 20, 2014, 09:17:30 PM
 #34

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

EricKennedy
Sr. Member
****
Offline Offline

Activity: 360

CEO, Ledger


View Profile WWW
April 20, 2014, 09:51:50 PM
 #35

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

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

NanoAkron
Sr. Member
****
Offline Offline

Activity: 252


View Profile
April 20, 2014, 10:35:49 PM
 #36

Where is the problem for this solution?

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

Activity: 360

CEO, Ledger


View Profile WWW
April 21, 2014, 10:58:43 AM
 #37

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

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

ecrick3
Newbie
*
Offline Offline

Activity: 23


View Profile
April 21, 2014, 11:01:55 AM
 #38

any1 try Python implementation yet?
laurentmt
Sr. Member
****
Offline Offline

Activity: 386


View Profile
April 27, 2014, 05:41:11 PM
 #39

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

Activity: 22


View Profile
April 28, 2014, 04:27:22 AM
 #40

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.

PGP:  *Link Removed*
EricKennedy
Sr. Member
****
Offline Offline

Activity: 360

CEO, Ledger


View Profile WWW
April 28, 2014, 09:55:52 AM
 #41

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

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

The other possible solutions to avoid CAPTCHA are :
  • Coin sacrifice
  • send a not trivial amount to the service in escrow (2 of 2 multisig)
  • just pay the service 0.001 BTC (for instance) to unlock privileges

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

Eric



laurentmt
Sr. Member
****
Offline Offline

Activity: 386


View Profile
April 28, 2014, 03:01:07 PM
 #42

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

gacrux
Newbie
*
Offline Offline

Activity: 22


View Profile
April 29, 2014, 05:14:10 AM
 #43

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 ?

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.


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.

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.


The other possible solutions to avoid CAPTCHA are :
  • Coin sacrifice
  • send a not trivial amount to the service in escrow (2 of 2 multisig)
  • just pay the service 0.001 BTC (for instance) to unlock privileges

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

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.


PGP:  *Link Removed*
gacrux
Newbie
*
Offline Offline

Activity: 22


View Profile
April 29, 2014, 05:51:28 AM
 #44

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

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.

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 !

Completely tangential use case sorry Smiley 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 Tongue 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 Smiley

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.


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.

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 Smiley

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.

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.



PGP:  *Link Removed*
EricKennedy
Sr. Member
****
Offline Offline

Activity: 360

CEO, Ledger


View Profile WWW
April 29, 2014, 08:14:04 AM
 #45

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

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



NanoAkron
Sr. Member
****
Offline Offline

Activity: 252


View Profile
April 29, 2014, 09:07:41 AM
 #46

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

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.
laurentmt
Sr. Member
****
Offline Offline

Activity: 386


View Profile
April 29, 2014, 12:02:06 PM
 #47

Quote
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. 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.
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.  Wink

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...  Roll Eyes
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.
EricKennedy
Sr. Member
****
Offline Offline

Activity: 360

CEO, Ledger


View Profile WWW
April 29, 2014, 12:04:45 PM
 #48

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.

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.

gacrux
Newbie
*
Offline Offline

Activity: 22


View Profile
April 29, 2014, 01:04:56 PM
 #49

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

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


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

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

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.

PGP:  *Link Removed*
gacrux
Newbie
*
Offline Offline

Activity: 22


View Profile
April 29, 2014, 01:26:27 PM
 #50

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.

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.

PGP:  *Link Removed*
gacrux
Newbie
*
Offline Offline

Activity: 22


View Profile
April 29, 2014, 01:47:13 PM
 #51

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.

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.


PGP:  *Link Removed*
gacrux
Newbie
*
Offline Offline

Activity: 22


View Profile
April 29, 2014, 02:07:36 PM
 #52

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 ?

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




PGP:  *Link Removed*
laurentmt
Sr. Member
****
Offline Offline

Activity: 386


View Profile
April 29, 2014, 02:16:52 PM
 #53

Quote
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.
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.  Smiley
NanoAkron
Sr. Member
****
Offline Offline

Activity: 252


View Profile
April 29, 2014, 02:22:06 PM
 #54

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 ?

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





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.
gacrux
Newbie
*
Offline Offline

Activity: 22


View Profile
April 30, 2014, 02:59:12 PM
 #55

- Am I right if I say that in this system, stake is validated only one time when creating the account ?

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.

- Who generates what you've called the BitId QRSTUVWXYZ (user or website) ?

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

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 ?

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.

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

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.


PGP:  *Link Removed*
gacrux
Newbie
*
Offline Offline

Activity: 22


View Profile
April 30, 2014, 03:10:09 PM
 #56

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.

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.

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.

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

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.

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

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

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.

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

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.

Not a trust system.

PGP:  *Link Removed*
NanoAkron
Sr. Member
****
Offline Offline

Activity: 252


View Profile
April 30, 2014, 07:40:48 PM
 #57

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.
gacrux
Newbie
*
Offline Offline

Activity: 22


View Profile
May 01, 2014, 12:19:52 AM
 #58

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



PGP:  *Link Removed*
laurentmt
Sr. Member
****
Offline Offline

Activity: 386


View Profile
May 03, 2014, 04:01:33 PM
 #59

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 !
laurentmt
Sr. Member
****
Offline Offline

Activity: 386


View Profile
May 03, 2014, 04:22:53 PM
 #60

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.
I think I get the idea now.  Roll Eyes
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).
EricKennedy
Sr. Member
****
Offline Offline

Activity: 360

CEO, Ledger


View Profile WWW
May 08, 2014, 09:15:59 PM
 #61

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

Mitchell
Staff
Legendary
*
Offline Offline

Activity: 1568


Verified awesomeness ✔


View Profile WWW
May 13, 2014, 01:04:03 PM
 #62

I don't know if this has been posted before but BitID is on CoinDesk: Authentication Protocol BitID Lets Users ‘Connect with Bitcoin’

          ▄█████▄
        ▄█████████▄
      ▄████▀   ▀████▄
    ▄████▀   ▄ ▄█▀████▄
  ▄████▀   ▄███▀   ▀████▄
▄████▀   ▄███▀   ▄   ▀████▄
█████   ███▀   ▄███   █████
▀████▄   ▀██▄▄███▀   ▄████▀
  ▀████▄   ▀███▀   ▄████▀
    ▀████▄       ▄████▀
      ▀████▄   ▄████▀
        ▀███  ████▀
          ▀█▄███▀
.
|
.
|
          ▄█████▄
        ▄█████████▄
      ▄████▀   ▀████▄
    ▄████▀   ▄ ▄█▀████▄
  ▄████▀   ▄███▀   ▀████▄
▄████▀   ▄███▀   ▄   ▀████▄
█████   ███▀   ▄███   █████
▀████▄   ▀██▄▄███▀   ▄████▀
  ▀████▄   ▀███▀   ▄████▀
    ▀████▄       ▄████▀
      ▀████▄   ▄████▀
        ▀███  ████▀
          ▀█▄███▀
unthy
sclaggett
Jr. Member
*
Offline Offline

Activity: 45


View Profile
May 13, 2014, 03:38:55 PM
 #63

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?
Mitchell
Staff
Legendary
*
Offline Offline

Activity: 1568


Verified awesomeness ✔


View Profile WWW
May 13, 2014, 05:53:18 PM
 #64

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

          ▄█████▄
        ▄█████████▄
      ▄████▀   ▀████▄
    ▄████▀   ▄ ▄█▀████▄
  ▄████▀   ▄███▀   ▀████▄
▄████▀   ▄███▀   ▄   ▀████▄
█████   ███▀   ▄███   █████
▀████▄   ▀██▄▄███▀   ▄████▀
  ▀████▄   ▀███▀   ▄████▀
    ▀████▄       ▄████▀
      ▀████▄   ▄████▀
        ▀███  ████▀
          ▀█▄███▀
.
|
.
|
          ▄█████▄
        ▄█████████▄
      ▄████▀   ▀████▄
    ▄████▀   ▄ ▄█▀████▄
  ▄████▀   ▄███▀   ▀████▄
▄████▀   ▄███▀   ▄   ▀████▄
█████   ███▀   ▄███   █████
▀████▄   ▀██▄▄███▀   ▄████▀
  ▀████▄   ▀███▀   ▄████▀
    ▀████▄       ▄████▀
      ▀████▄   ▄████▀
        ▀███  ████▀
          ▀█▄███▀
unthy
laurentmt
Sr. Member
****
Offline Offline

Activity: 386


View Profile
May 14, 2014, 03:24:25 PM
 #65

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?

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...
wbaw
Member
**
Offline Offline

Activity: 62


View Profile WWW
May 16, 2014, 01:03:34 AM
 #66

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.

EricKennedy
Sr. Member
****
Offline Offline

Activity: 360

CEO, Ledger


View Profile WWW
May 16, 2014, 08:38:51 AM
 #67

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

EricKennedy
Sr. Member
****
Offline Offline

Activity: 360

CEO, Ledger


View Profile WWW
May 17, 2014, 11:26:20 AM
 #68

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

Mitchell
Staff
Legendary
*
Offline Offline

Activity: 1568


Verified awesomeness ✔


View Profile WWW
May 17, 2014, 11:35:22 AM
 #69

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

          ▄█████▄
        ▄█████████▄
      ▄████▀   ▀████▄
    ▄████▀   ▄ ▄█▀████▄
  ▄████▀   ▄███▀   ▀████▄
▄████▀   ▄███▀   ▄   ▀████▄
█████   ███▀   ▄███   █████
▀████▄   ▀██▄▄███▀   ▄████▀
  ▀████▄   ▀███▀   ▄████▀
    ▀████▄       ▄████▀
      ▀████▄   ▄████▀
        ▀███  ████▀
          ▀█▄███▀
.
|
.
|
          ▄█████▄
        ▄█████████▄
      ▄████▀   ▀████▄
    ▄████▀   ▄ ▄█▀████▄
  ▄████▀   ▄███▀   ▀████▄
▄████▀   ▄███▀   ▄   ▀████▄
█████   ███▀   ▄███   █████
▀████▄   ▀██▄▄███▀   ▄████▀
  ▀████▄   ▀███▀   ▄████▀
    ▀████▄       ▄████▀
      ▀████▄   ▄████▀
        ▀███  ████▀
          ▀█▄███▀
unthy
daniel.socials
Newbie
*
Offline Offline

Activity: 5

love program, hate programer


View Profile
May 22, 2014, 09:05:10 AM
 #70

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

Activity: 1568


Verified awesomeness ✔


View Profile WWW
May 22, 2014, 09:18:30 AM
 #71

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!

          ▄█████▄
        ▄█████████▄
      ▄████▀   ▀████▄
    ▄████▀   ▄ ▄█▀████▄
  ▄████▀   ▄███▀   ▀████▄
▄████▀   ▄███▀   ▄   ▀████▄
█████   ███▀   ▄███   █████
▀████▄   ▀██▄▄███▀   ▄████▀
  ▀████▄   ▀███▀   ▄████▀
    ▀████▄       ▄████▀
      ▀████▄   ▄████▀
        ▀███  ████▀
          ▀█▄███▀
.
|
.
|
          ▄█████▄
        ▄█████████▄
      ▄████▀   ▀████▄
    ▄████▀   ▄ ▄█▀████▄
  ▄████▀   ▄███▀   ▀████▄
▄████▀   ▄███▀   ▄   ▀████▄
█████   ███▀   ▄███   █████
▀████▄   ▀██▄▄███▀   ▄████▀
  ▀████▄   ▀███▀   ▄████▀
    ▀████▄       ▄████▀
      ▀████▄   ▄████▀
        ▀███  ████▀
          ▀█▄███▀
unthy
OneBTCJay
Newbie
*
Offline Offline

Activity: 27


View Profile
May 22, 2014, 11:49:58 PM
 #72

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:

Code:
$ telnet localhost
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Ubuntu 13.10
bitcoin address: 1DvRd44mD8EuCcym8zymYzabvmozwZ5r8G
challenge message: dbcbd542b29a3c4298651035ae6eaed3
signature: HE8DDp4eAEy61417XTPAQTOqPBcLP2h0Y0sTB9hfFILCv8ZpLzdH6dh/z6+o7A4VwwjM1Qq2SFVcgyf7U51JhdE=
Last login: Wed May 21 18:42:01 PDT 2014 from localhost on pts/17
Welcome to Ubuntu 13.10 (GNU/Linux 3.11.0-12-generic x86_64)

btctest:~$
laurentmt
Sr. Member
****
Offline Offline

Activity: 386


View Profile
May 31, 2014, 07:00:09 PM
 #73

Thanks to manuelzs, django developers can now play with BitId (Github - Pypy)
Falkvinge
Jr. Member
*
Offline Offline

Activity: 31


View Profile
June 15, 2014, 03:21:08 PM
 #74

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
EricKennedy
Sr. Member
****
Offline Offline

Activity: 360

CEO, Ledger


View Profile WWW
June 16, 2014, 09:10:04 AM
 #75

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 Smiley I wish I could find another Android coder to help me.

Eric

Mitchell
Staff
Legendary
*
Offline Offline

Activity: 1568


Verified awesomeness ✔


View Profile WWW
June 25, 2014, 10:53:41 AM
 #76

Quote
Andreas Petersson
Diskussion  -  12:39
v1.2.15 pushed to github, testnet + beta testers.

please have a close look at the latest changes
*) email notifications for local trader
*) navigation bugfixes after notifications
*) experimental BitID support (testnet only)
Source: Google+ Beta Tester Group

Going good Eric Grin

          ▄█████▄
        ▄█████████▄
      ▄████▀   ▀████▄
    ▄████▀   ▄ ▄█▀████▄
  ▄████▀   ▄███▀   ▀████▄
▄████▀   ▄███▀   ▄   ▀████▄
█████   ███▀   ▄███   █████
▀████▄   ▀██▄▄███▀   ▄████▀
  ▀████▄   ▀███▀   ▄████▀
    ▀████▄       ▄████▀
      ▀████▄   ▄████▀
        ▀███  ████▀
          ▀█▄███▀
.
|
.
|
          ▄█████▄
        ▄█████████▄
      ▄████▀   ▀████▄
    ▄████▀   ▄ ▄█▀████▄
  ▄████▀   ▄███▀   ▀████▄
▄████▀   ▄███▀   ▄   ▀████▄
█████   ███▀   ▄███   █████
▀████▄   ▀██▄▄███▀   ▄████▀
  ▀████▄   ▀███▀   ▄████▀
    ▀████▄       ▄████▀
      ▀████▄   ▄████▀
        ▀███  ████▀
          ▀█▄███▀
unthy
Mitchell
Staff
Legendary
*
Offline Offline

Activity: 1568


Verified awesomeness ✔


View Profile WWW
July 01, 2014, 09:26:49 PM
 #77

BitAuth seems to look a lot like BitID or am I just plain stupid?

          ▄█████▄
        ▄█████████▄
      ▄████▀   ▀████▄
    ▄████▀   ▄ ▄█▀████▄
  ▄████▀   ▄███▀   ▀████▄
▄████▀   ▄███▀   ▄   ▀████▄
█████   ███▀   ▄███   █████
▀████▄   ▀██▄▄███▀   ▄████▀
  ▀████▄   ▀███▀   ▄████▀
    ▀████▄       ▄████▀
      ▀████▄   ▄████▀
        ▀███  ████▀
          ▀█▄███▀
.
|
.
|
          ▄█████▄
        ▄█████████▄
      ▄████▀   ▀████▄
    ▄████▀   ▄ ▄█▀████▄
  ▄████▀   ▄███▀   ▀████▄
▄████▀   ▄███▀   ▄   ▀████▄
█████   ███▀   ▄███   █████
▀████▄   ▀██▄▄███▀   ▄████▀
  ▀████▄   ▀███▀   ▄████▀
    ▀████▄       ▄████▀
      ▀████▄   ▄████▀
        ▀███  ████▀
          ▀█▄███▀
unthy
laurentmt
Sr. Member
****
Offline Offline

Activity: 386


View Profile
July 01, 2014, 11:18:23 PM
 #78

BitAuth seems to look a lot like BitID or am I just plain stupid?
Grin
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.
trasla
Hero Member
*****
Offline Offline

Activity: 713



View Profile
July 11, 2014, 01:19:41 PM
 #79

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.
EricKennedy
Sr. Member
****
Offline Offline

Activity: 360

CEO, Ledger


View Profile WWW
July 11, 2014, 01:30:36 PM
 #80

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.

wbaw
Member
**
Offline Offline

Activity: 62


View Profile WWW
July 30, 2014, 12:13:04 PM
 #81

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

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.

laurentmt
Sr. Member
****
Offline Offline

Activity: 386


View Profile
August 05, 2014, 12:49:53 AM
 #82

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.
ALL IN
Newbie
*
Offline Offline

Activity: 16


View Profile
August 05, 2014, 01:35:23 AM
 #83

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.

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
fran2k
Hero Member
*****
Offline Offline

Activity: 770


View Profile WWW
August 07, 2014, 01:58:47 AM
 #84

This is awesome, great work.
Razick
Legendary
*
Offline Offline

Activity: 896


Enjin Coin - Smart Cryptocurrency for Gaming.


View Profile
August 10, 2014, 02:58:27 AM
 #85

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

Rassah
Legendary
*
Offline Offline

Activity: 1680


Director of Bitcoin100


View Profile
August 14, 2014, 04:32:31 AM
 #86

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

gweedo
Legendary
*
Offline Offline

Activity: 1246


Java, PHP, HTML/CSS Programmer for Hire!


View Profile WWW
August 14, 2014, 04:47:41 AM
 #87

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?

Want to earn 2500 SATOSHIS per hour? Come Chat and Chill in https://goseemybits.com/lobby
EricKennedy
Sr. Member
****
Offline Offline

Activity: 360

CEO, Ledger


View Profile WWW
August 14, 2014, 06:18:36 AM
 #88

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.

Rassah
Legendary
*
Offline Offline

Activity: 1680


Director of Bitcoin100


View Profile
August 14, 2014, 01:27:39 PM
 #89

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?

EricKennedy
Sr. Member
****
Offline Offline

Activity: 360

CEO, Ledger


View Profile WWW
August 14, 2014, 03:05:18 PM
 #90

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.

Rassah
Legendary
*
Offline Offline

Activity: 1680


Director of Bitcoin100


View Profile
August 14, 2014, 03:38:34 PM
 #91

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?

laurentmt
Sr. Member
****
Offline Offline

Activity: 386


View Profile
August 14, 2014, 04:57:25 PM
 #92

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) 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
wbaw
Member
**
Offline Offline

Activity: 62


View Profile WWW
August 16, 2014, 03:52:39 AM
 #93

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.

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.

laurentmt
Sr. Member
****
Offline Offline

Activity: 386


View Profile
August 16, 2014, 04:59:24 PM
 #94

Hi wbaw,

No, you're still misunderstanding, nameid.org just uses openid as an example, it doesn't rely on openid at all, ...
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

Quote
Namecoin + OpenID = NameID !
If you remove OpenID from NameID, it's no longer NameID.


It sends a message, you sign it with the key used for your namecoin id, the site checks the signature...
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.


... it relies on Namecoin ID.
...
It works almost exactly like BitID, but pre-dates it & allows you to link it to your ID information stored in Namecoin.
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 !


Falkvinge
Jr. Member
*
Offline Offline

Activity: 31


View Profile
August 19, 2014, 08:25:50 PM
 #95

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
Falkvinge
Jr. Member
*
Offline Offline

Activity: 31


View Profile
August 19, 2014, 08:45:11 PM
 #96

(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?)
EricKennedy
Sr. Member
****
Offline Offline

Activity: 360

CEO, Ledger


View Profile WWW
August 20, 2014, 07:23:48 AM
 #97

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.

Falkvinge
Jr. Member
*
Offline Offline

Activity: 31


View Profile
August 20, 2014, 03:03:12 PM
 #98

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.

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
Rassah
Legendary
*
Offline Offline

Activity: 1680


Director of Bitcoin100


View Profile
August 20, 2014, 09:17:03 PM
 #99

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"?

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.

laurentmt
Sr. Member
****
Offline Offline

Activity: 386


View Profile
August 23, 2014, 01:24:30 AM
 #100

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/
12Lc7Wxjtpe
Member
**
Offline Offline

Activity: 83


View Profile
August 24, 2014, 10:54:34 AM
 #101

A combination of this and onename.io would be great
dillpicklechips
Hero Member
*****
Offline Offline

Activity: 630


🌟  ATLANT ICO: 07/09/17 🌟


View Profile
September 10, 2014, 07:27:50 PM
 #102

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

......ATLANT......
..Real Estate Blockchain Platform..
                    ▄▄▄▄▄▄▄▄▄
                    ████████████░
                  ▄██████████████░
                 ▒███████▄████████░
                ▒█████████░████████░
                ▀███████▀█████████
                  ██████████████
           ███████▐██▀████▐██▄████████░
          ▄████▄█████████▒████▌█████████░
         ███████▄█████████▀██████████████░
        █████████▌█████████▐█████▄████████░
        ▀█████████████████▐███████████████
          █████▀████████ ░███████████████
    ██████▐██████████▄████████████████████████░
  ▄████▄████████▐███████████████░▄▄▄▄░████████░
 ▄██████▄█████████▐█████▄█████████▀████▄█████████░
███████████████████▐█████▄█████████▐██████████████░
▀████████▀█████████▒██████████████▐█████▀█████████
  ████████████████ █████▀█████████████████████████
   ▀██▀██████████ ▐█████████████  ▀██▀██████████
    ▀▀█████████    ▀▀█████████    ▀▀██████████

..INVEST  ●  RENT  ●  TRADE..
 ✓Assurance     ✓Price Discovery     ✓Liquidity     ✓Low Fees





███
███
███
███
███
███





███
███
███
███
███
███
███
███
███
███
███
███

◣Whitepaper ◣ANN ThreadTelegram
◣ Facebook     ◣ Reddit          ◣ Slack


███
███
███
███
███
███
███
███
███
███
███
███





███
███
███
███
███
███



onchain.io
Newbie
*
Offline Offline

Activity: 29


View Profile WWW
September 11, 2014, 10:15:50 AM
 #103

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/



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.

Code:
Started POST "/callback" for 192.168.178.39 at 2014-09-11 12:07:05 +0200
{"signature"=>"ICmRRZees1ERGP0zFRpjlzNA60e3b9GYAwScGbpqe7Lnek6ulUwTB3VXkWkH1ZbaPirEf60EKrWGAXE0BqMSETI=", "uri"=>"bitid://192.168.178.29:3000/callback?x=463eb9f064a4173f&u=1", "address"=>"1PmcrixixGKzSyL6NbNcSzjHGLSsgb7dfa"}

onchain.io
onchain.io
Newbie
*
Offline Offline

Activity: 29


View Profile WWW
September 11, 2014, 01:23:01 PM
 #104

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.

onchain.io
laurentmt
Sr. Member
****
Offline Offline

Activity: 386


View Profile
September 11, 2014, 01:42:14 PM
 #105

Hi onchain !

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

Code:
Started POST "/callback" for 192.168.178.39 at 2014-09-11 12:07:05 +0200
{"signature"=>"ICmRRZees1ERGP0zFRpjlzNA60e3b9GYAwScGbpqe7Lnek6ulUwTB3VXkWkH1ZbaPirEf60EKrWGAXE0BqMSETI=", "uri"=>"bitid://192.168.178.29:3000/callback?x=463eb9f064a4173f&u=1", "address"=>"1PmcrixixGKzSyL6NbNcSzjHGLSsgb7dfa"}
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.

onchain.io
Newbie
*
Offline Offline

Activity: 29


View Profile WWW
September 11, 2014, 01:48:37 PM
 #106

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 ?

That's correct.

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.

I'll do some extra debug now. Thanks.

onchain.io
onchain.io
Newbie
*
Offline Offline

Activity: 29


View Profile WWW
September 11, 2014, 01:59:45 PM
 #107

OK, thanks. Seems to be working now.

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

onchain.io
laurentmt
Sr. Member
****
Offline Offline

Activity: 386


View Profile
September 11, 2014, 02:00:59 PM
 #108

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 Smiley
Cool ! What was the problem ?
onchain.io
Newbie
*
Offline Offline

Activity: 29


View Profile WWW
September 11, 2014, 02:04:19 PM
 #109

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

onchain.io
laurentmt
Sr. Member
****
Offline Offline

Activity: 386


View Profile
September 11, 2014, 02:09:14 PM
 #110

Not sure. It's working now, that's the main thing. Smiley
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
onchain.io
Newbie
*
Offline Offline

Activity: 29


View Profile WWW
September 11, 2014, 02:11:30 PM
 #111

I'll add it to my list of test platforms with Dark Wallet.

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

onchain.io
laurentmt
Sr. Member
****
Offline Offline

Activity: 386


View Profile
September 11, 2014, 02:16:19 PM
 #112

Dark Wallet supports BitID ? Do you have a link I can look at.
They do, since their last release (alpha 5)
trasla
Hero Member
*****
Offline Offline

Activity: 713



View Profile
September 12, 2014, 09:34:19 AM
 #113

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 Smiley

(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))
laurentmt
Sr. Member
****
Offline Offline

Activity: 386


View Profile
September 12, 2014, 04:31:25 PM
 #114

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 Smiley
(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  Roll Eyes
Rassah
Legendary
*
Offline Offline

Activity: 1680


Director of Bitcoin100


View Profile
September 12, 2014, 09:09:07 PM
 #115

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 Smiley

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

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

xchrix
Hero Member
*****
Offline Offline

Activity: 907



View Profile WWW
October 21, 2014, 09:41:04 PM
 #116

I can confirm the demo on http://vps90685.ovh.net:8080/ works with mycelium wallet, too.

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?

www.cryptocoincharts.info - long term charts for 800+ coins like BTC, LTC, NXT, DOGE
www.cryptoassetcharts.info - charts for decentralized assets like NXT AE, XCP, MSC, ...
BTC donations: 1DRVMYRMFafdtXJF1tivwyoR1SF8LDNKWj
Bitrated user: cryptocoinchart.
trasla
Hero Member
*****
Offline Offline

Activity: 713



View Profile
October 22, 2014, 10:07:53 AM
 #117

I can confirm the demo on http://vps90685.ovh.net:8080/ works with mycelium wallet, too.

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.
laurentmt
Sr. Member
****
Offline Offline

Activity: 386


View Profile
October 22, 2014, 12:17:43 PM
 #118

I can confirm the demo on http://vps90685.ovh.net:8080/ works with mycelium wallet, too.

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/
Mitchell
Staff
Legendary
*
Offline Offline

Activity: 1568


Verified awesomeness ✔


View Profile WWW
October 22, 2014, 12:36:47 PM
 #119

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

          ▄█████▄
        ▄█████████▄
      ▄████▀   ▀████▄
    ▄████▀   ▄ ▄█▀████▄
  ▄████▀   ▄███▀   ▀████▄
▄████▀   ▄███▀   ▄   ▀████▄
█████   ███▀   ▄███   █████
▀████▄   ▀██▄▄███▀   ▄████▀
  ▀████▄   ▀███▀   ▄████▀
    ▀████▄       ▄████▀
      ▀████▄   ▄████▀
        ▀███  ████▀
          ▀█▄███▀
.
|
.
|
          ▄█████▄
        ▄█████████▄
      ▄████▀   ▀████▄
    ▄████▀   ▄ ▄█▀████▄
  ▄████▀   ▄███▀   ▀████▄
▄████▀   ▄███▀   ▄   ▀████▄
█████   ███▀   ▄███   █████
▀████▄   ▀██▄▄███▀   ▄████▀
  ▀████▄   ▀███▀   ▄████▀
    ▀████▄       ▄████▀
      ▀████▄   ▄████▀
        ▀███  ████▀
          ▀█▄███▀
unthy
Falkvinge
Jr. Member
*
Offline Offline

Activity: 31


View Profile
October 27, 2014, 08:50:22 AM
 #120

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)
bernard75
Legendary
*
Offline Offline

Activity: 1134



View Profile
October 27, 2014, 09:35:20 AM
 #121

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. Wink
Thumbs up here too.
laurentmt
Sr. Member
****
Offline Offline

Activity: 386


View Profile
October 27, 2014, 10:02:44 AM
 #122

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)

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
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 (original code)
- Python
- JS
- PHP

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


Thumbs up here too.
You're welcome  Smiley
Falkvinge
Jr. Member
*
Offline Offline

Activity: 31


View Profile
October 29, 2014, 02:25:35 PM
 #123

Some feedback - this part was not clear to me:

Quote
POST the signature, the URI and the public key to the callback URL

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?
CIYAM
Legendary
*
Offline Offline

Activity: 1848


Ian Knowles - CIYAM Lead Developer


View Profile WWW
October 29, 2014, 02:30:15 PM
 #124

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.

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
trasla
Hero Member
*****
Offline Offline

Activity: 713



View Profile
October 29, 2014, 03:27:42 PM
 #125

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?
CIYAM
Legendary
*
Offline Offline

Activity: 1848


Ian Knowles - CIYAM Lead Developer


View Profile WWW
October 29, 2014, 03:32:23 PM
 #126

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

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
trasla
Hero Member
*****
Offline Offline

Activity: 713



View Profile
October 29, 2014, 06:34:07 PM
 #127

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.
EricKennedy
Sr. Member
****
Offline Offline

Activity: 360

CEO, Ledger


View Profile WWW
October 29, 2014, 08:08:43 PM
 #128

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?

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.

Falkvinge
Jr. Member
*
Offline Offline

Activity: 31


View Profile
October 29, 2014, 08:18:33 PM
 #129

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

Quote
POST /Security/BitId HTTP/1.1
Host: bitid.example.com
Content-Type: application/json

{ "addr":"1dsfagahigaeguropiaasdazd","sign":"ÖIUYFQ(Et5yn9se8hgs8f9dghjf","callback_uri":"https://bitid.example.com","bitid_uri":"https://login.example.com" }

SAMPLE SERVER RESPONSE

Quote
200 OK
(a HTTP 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
laurentmt
Sr. Member
****
Offline Offline

Activity: 386


View Profile
October 29, 2014, 09:39:38 PM
 #130

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

Quote
/callback

Request sent by the browser or the wallet as a response to a challenge Request can be sent in two formats: json or html form

Request

    Http method: POST

    Parameters:
        uri : string - required - bitid uri used as the challenge
        signature : string - required - signature of the bitid uri
        address : string - required - address used for authentication

    Headers:
        Content-Type : string - required = "application/json" if request sent by a wallet, otherwise server should assume a manual signing submitted via an html form (see demo)

Response

    Process completed

        Response format:
            address : string - required - address used for authentication
            nonce : string - required - session id associated to the authentication

        Http code: 200

    Process failed

        Response format:
            message : string - required(?) - message describing the error

        Http codes / messages:
            Invalid adress
                Http code : 401
                message : Address is invalid or not legal
            Address is valid but not associated to an existing account
                Http code : 401
                message : Address is invalid or not legal
            Invalid BitId uri
                Http code : 401
                message : BitID URI is invalid or not legal
            Invalid signature
                Http code : 401
                message : Signature is incorrect
            Illegal nonce
                Http code : 401
                message : NONCE is illegal
            Expired nonce
                Http code : 401
                message : NONCE has expired
            Server error (pb with db, ...)
                Http code : 500
                message : Huh
            Misc error (specific to implementations by websites)
                Http code : 401
                message : [...]


/auth

Request sent by the browser to check if authentication has succeeded

Request

    Http method: GET

    Parameters: None

    Headers Cookie: stores the session id

Response

    Process completed

        Response format:
            auth : int - required - 1 if authentication successfully completed, otherwise 0

        Http code: 200

Falkvinge
Jr. Member
*
Offline Offline

Activity: 31


View Profile
October 29, 2014, 10:05:06 PM
 #131

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.

Quote
/callback

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.

Quote
   Parameters:
        uri : string - required - bitid uri used as the challenge
        signature : string - required - signature of the bitid uri
        address : string - required - address used for authentication

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
laurentmt
Sr. Member
****
Offline Offline

Activity: 386


View Profile
October 29, 2014, 10:49:29 PM
 #132

Sorry for the late answer. Was musing in the french subforum  Roll Eyes

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.
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 (uses a "/tfa_activation_callback" uri)

Quote
   Parameters:
        uri : string - required - bitid uri used as the challenge
        signature : string - required - signature of the bitid uri
        address : string - required - address used for authentication

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

Falkvinge
Jr. Member
*
Offline Offline

Activity: 31


View Profile
October 30, 2014, 03:42:39 AM
 #133

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:

Quote
POST http://dev.swarmops.com/Security/BitId.aspx HTTP/1.0
Content-Length: 272
Content-Type: application/x-www-form-urlencoded
Accept-Encoding: gzip
Host: dev.swarmops.com
User-Agent: android-async-http/1.4.4 (http://loopj.com/android-async-http)

signature=H2ooalc68rfcS%2FnEIrrCH2zUKYvjIuj%2Bp9DoQoVVkW39R3wVfNnbO7Pmd4UdkNf6FpQ%2FUGV3pfm4vrE9541za%2Fg%3D&uri=bitid%3A%2F%2Fdev.swarmops.com%2FSecurity%2FBitId.aspx%3Fx%3D4b593383a4674b83b31d066e0e87e60f8d1c1df565f568f%26u%3D1&address=14fRQCbR62EGzjPQks9XRAVRiqWhftn3dA

And here I was trying to interpret Json and wonder why the server did absolutely nothing... Smiley
Falkvinge
Jr. Member
*
Offline Offline

Activity: 31


View Profile
October 30, 2014, 03:44:17 AM
 #134

Ooops. That sounds like a more serious issue.
On its side, BitID protocol does not state any specific order for the parameters.

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.

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
cbeast
Donator
Legendary
*
Offline Offline

Activity: 1736

Let's talk governance, lipstick, and pigs.


View Profile
October 30, 2014, 05:36:31 AM
 #135

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"?

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.
This is big.

Any significantly advanced cryptocurrency is indistinguishable from Ponzi Tulips.
trasla
Hero Member
*****
Offline Offline

Activity: 713



View Profile
October 30, 2014, 09:56:46 AM
 #136

This is big.

It is enabled in the mycelium testnet app, if you want to try. Smiley
laurentmt
Sr. Member
****
Offline Offline

Activity: 386


View Profile
October 30, 2014, 12:33:34 PM
 #137

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

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

Quote
POST http://dev.swarmops.com/Security/BitId.aspx HTTP/1.0
Content-Length: 272
Content-Type: application/x-www-form-urlencoded
Accept-Encoding: gzip
Host: dev.swarmops.com
User-Agent: android-async-http/1.4.4 (http://loopj.com/android-async-http)

signature=H2ooalc68rfcS%2FnEIrrCH2zUKYvjIuj%2Bp9DoQoVVkW39R3wVfNnbO7Pmd4UdkNf6FpQ%2FUGV3pfm4vrE9541za%2Fg%3D&uri=bitid%3A%2F%2Fdev.swarmops.com%2FSecurity%2FBitId.aspx%3Fx%3D4b593383a4674b83b31d066e0e87e60f8d1c1df565f568f%26u%3D1&address=14fRQCbR62EGzjPQks9XRAVRiqWhftn3dA
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.


And here I was trying to interpret Json and wonder why the server did absolutely nothing... Smiley
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.  Wink
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.
Falkvinge
Jr. Member
*
Offline Offline

Activity: 31


View Profile
October 30, 2014, 11:25:28 PM
 #138

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
laurentmt
Sr. Member
****
Offline Offline

Activity: 386


View Profile
October 31, 2014, 12:39:53 PM
 #139

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

Quote
'Last-Modified' = '<DateTime.Now>'
'Cache-Control' = 'no-store, no-cache, must-revalidate, post-check=0, pre-check=0'
'Pragma' = 'no-cache'
lonelyminer (Peter Šurda)
Donator
Hero Member
*
Offline Offline

Activity: 544


View Profile
January 17, 2015, 05:13:53 PM
 #140

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.
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
lonelyminer (Peter Šurda)
Donator
Hero Member
*
Offline Offline

Activity: 544


View Profile
January 20, 2015, 10:55:15 PM
 #141

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.
I made a youtube video to show how cool it is: https://www.youtube.com/watch?v=U6I4HuzSTM0.
marcus_of_augustus
Legendary
*
Offline Offline

Activity: 2380



View Profile
January 21, 2015, 02:14:25 AM
 #142

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.
I made a youtube video to show how cool it is: https://www.youtube.com/watch?v=U6I4HuzSTM0.

this is pretty cool.

CIYAM
Legendary
*
Offline Offline

Activity: 1848


Ian Knowles - CIYAM Lead Developer


View Profile WWW
January 21, 2015, 05:09:05 AM
 #143

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

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
lonelyminer (Peter Šurda)
Donator
Hero Member
*
Offline Offline

Activity: 544


View Profile
January 21, 2015, 08:54:47 AM
 #144

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.
CIYAM
Legendary
*
Offline Offline

Activity: 1848


Ian Knowles - CIYAM Lead Developer


View Profile WWW
January 21, 2015, 09:12:26 AM
 #145

Thanks - very interesting.

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
human
Full Member
***
Offline Offline

Activity: 194

æternity - the oracle blockchain


View Profile WWW
February 26, 2015, 12:57:36 PM
 #146

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.

EricKennedy
Sr. Member
****
Offline Offline

Activity: 360

CEO, Ledger


View Profile WWW
April 01, 2015, 10:46:11 AM
 #147

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

Code is pretty straightforward:

Code:
<script src="http//www.ledgerwallet.com/lib/ledger.js"></script>

<button class="btn btn-success" type="button"
  onclick="Ledger.bitid('BITID_URL')">
  Login with your Ledger Wallet
</button>

<script>
  Ledger.init({ callback: function() {} });
</script>

xchrix
Hero Member
*****
Offline Offline

Activity: 907



View Profile WWW
April 01, 2015, 05:27:22 PM
 #148

nice ledgerwallet!

www.cryptocoincharts.info - long term charts for 800+ coins like BTC, LTC, NXT, DOGE
www.cryptoassetcharts.info - charts for decentralized assets like NXT AE, XCP, MSC, ...
BTC donations: 1DRVMYRMFafdtXJF1tivwyoR1SF8LDNKWj
Bitrated user: cryptocoinchart.
Pages: 1 2 3 4 5 6 7 8 [All]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!