Eric Larchevêque [ARCHIVE] on Nostr: 📅 Original date posted:2014-04-22 📝 Original message:The development of BitID ...
📅 Original date posted:2014-04-22
📝 Original message:The development of BitID has had some progress, and we have now a working
wallet prototype based on Android Bitcoin Wallet (bitoinj).
The user flow is quite nice and if you are curious here is a short video
demonstration :
https://www.youtube.com/watch?v=3eepEWTnRTc
By default, each new first auth request will create and save a new address
(SQRL like). It could be based on BIP32, but this works also without.
This requires to add metadata to addresses, as described here :
https://github.com/bitid/bitid/blob/master/bitid_metadata.md
It open also the fields for decentralized 2FA as well as "pay as guest"
checkout in conjonction with BIP70 payment request.
Eric
On Tue, Apr 22, 2014 at 8:34 AM, Jan Møller <jan.moller at gmail.com> wrote:
> The reason why client side certificates have never gained traction because
> it is a pain to safely store/backup secrets.
> In bitcoinland we are forced to solve the problem of safely storing
> secrets, and over the years we have come up with software and hardware
> solutions to make this safer and easier to manage for ordinary people.
> Solving this is paramount to the success of Bitcoin, and nobody has solved
> it before on a grand scale.
>
> I see no reason for forcing end users to use two different mechanisms for
> safely managing secrets.
>
> I agree that using a bitcoin address for authentication purposes might be
> confusing and potentially linking your funds with your identity. So I am
> all for using something else than bitcoin addresses and bitcoin private
> keys.
>
> With bip32 we have finally agreed on a mechanism for generating a
> hierarchy of bitcoin private keys from a master seed. A similar approach
> can be used for generating a parallel hierarchy for authentication
> purposes.
>
> - Jan
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140422/97fad26c/attachment.html>
📝 Original message:The development of BitID has had some progress, and we have now a working
wallet prototype based on Android Bitcoin Wallet (bitoinj).
The user flow is quite nice and if you are curious here is a short video
demonstration :
https://www.youtube.com/watch?v=3eepEWTnRTc
By default, each new first auth request will create and save a new address
(SQRL like). It could be based on BIP32, but this works also without.
This requires to add metadata to addresses, as described here :
https://github.com/bitid/bitid/blob/master/bitid_metadata.md
It open also the fields for decentralized 2FA as well as "pay as guest"
checkout in conjonction with BIP70 payment request.
Eric
On Tue, Apr 22, 2014 at 8:34 AM, Jan Møller <jan.moller at gmail.com> wrote:
> The reason why client side certificates have never gained traction because
> it is a pain to safely store/backup secrets.
> In bitcoinland we are forced to solve the problem of safely storing
> secrets, and over the years we have come up with software and hardware
> solutions to make this safer and easier to manage for ordinary people.
> Solving this is paramount to the success of Bitcoin, and nobody has solved
> it before on a grand scale.
>
> I see no reason for forcing end users to use two different mechanisms for
> safely managing secrets.
>
> I agree that using a bitcoin address for authentication purposes might be
> confusing and potentially linking your funds with your identity. So I am
> all for using something else than bitcoin addresses and bitcoin private
> keys.
>
> With bip32 we have finally agreed on a mechanism for generating a
> hierarchy of bitcoin private keys from a master seed. A similar approach
> can be used for generating a parallel hierarchy for authentication
> purposes.
>
> - Jan
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140422/97fad26c/attachment.html>