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

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

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

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.

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.

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.

'Last-Modified' = ''
'Cache-Control' = 'no-store, no-cache, must-revalidate, post-check=0, pre-check=0'
'Pragma' = 'no-cache'

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

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

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

This is big.

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.

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.

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

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

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

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

   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

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

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.

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

200 OK
(a HTTP response)