[tonyhb]

This seems like the HMAC authorisation in OAuth 1, moved to HTTP via JS and custom headers. If the comparison is right, it should be a generally secure and easy to implement auth protocol.

It would be great for something like this to be commonplace, but the UI definitely needs to be solid. A few questions looking at it initially:

- How does the browser know your private keys?

- How does the browser know how to send the signed header?

- How are nonces managed (especially over multiple devices, if the new nonce always needs to be higher than a previously used one)?

- Can you have more than one SIN?

- If so, what's the benefit of having multiple SINs vs multiple passwords?

On a sidenote, bitpay make some seriously kick ass tools and I love how creative they are.

[martindale]

Multiple SINs (read: identities) are an intended benefit of this mechanism. In fact, nonces are verified per SIN, so this provides sequence enforcement per client as we intend for each device to have its own SIN.

We have a reference implementation for key management in [our example client](https://github.com/bitpay/node-bitpay-client)[1], and will be publishing a more formal document as soon as it is complete.

[1]: I am fully aware that HN does not support proper Markdown.

[siralonso]

Not only does HN not support markdown, but it breaks links you write using markdown :)

Really nice work. Question - if you generate the private keys client-side and use a password only to decrypt them for use (still client-side), wouldn't this make associating accounts across devices kinda difficult? As insecure as email/password auth is, it's pretty portable.

Looking forward to playing with bitauth!

[martindale]

Not particularly. The pattern for resolving this is already increasingly commonplace; login with your username and password, then confirm the login from one of your already authorized devices.

In fact, this even lends itself to expansion into n-factor authorization methods.