Andy Parkins [ARCHIVE] on Nostr: 📅 Original date posted:2012-11-27 📝 Original message:On Tuesday 27 November ...
📅 Original date posted:2012-11-27
📝 Original message:On Tuesday 27 November 2012 17:14:19 Mike Hearn wrote:
> That's pretty much what we have today - in future other schemes can be
> proposed as extensions. Protocol buffers are easily extended, they
> ignore unknown fields. Then you'd wait and see what the invoice
> request looked like and produce an invoice with the right security
> bits.
That's good; I've not done anything with protocol buffers, so wasn't aware it
was that simple.
> > In particular two additional identification types:
> > - GnuPG (obviously)
>
> It's not obvious to me, incidentally. The web of trust has been
> dead-on-arrival since it was first proposed, and for good reasons.
> SSL/X.509, for better or worse, has significant usage.
Sorry, I meant "obviously" in the sense that "obviously that's the other one
that everyone will want". The web-of-trust as a universal identity mechanism
is, I agree, not useful. However, as a localised, smaller-scale identity
verification system it's used by every GnuPG user. You become your own
certificate authority. For example, I've set up my whole family with GnuPG;
I've set them up to trust me to authenticate (and I doubt any of them has ever
added anyone else). Then I take on the responsibility of signing all my
family/friends keys and they don't need to worry about it.
There's no reason that a small group of companies wouldn't do exactly the same
sort of thing.
> Your case of a small business is a perfect example of people who won't
> be using GPG. If they don't want to buy an SSL cert, they can just as
Bear in mind, I was using that example as an example of a hash protected in a
GPG envelope, not a GPG-signed invoice. People who've already got their GPG
system in place will appreciate being able to leverage it.
> well put a reference number in the memo field or a "Hey Bob, here is
> the bill we discussed". The payer does not get the multi-factor auth
How can they put a hash of an invoice inside the invoice? In my "hash mode"
invoices, it would be a random number (or possibly specifying the hash
algorithm) then the SignedInvoice would simply be the original invoice + hash.
That hash would then be reported via some secure channel outside of bitcoin's
domain.
> protection so if their computer has a virus, they may be hosed. But
> that's good incentive for sellers to get verified. Some CA authorities
> do it for free these days.
I don't understand what the relevance of multi-factor is to invoices? The
payment is performed via normal bitcoin mechanisms isn't it -- multi-factor or
not? This invoice system has one primary job: to ensure that the target of
the payment is who the payer thinks it is -- that's not affected by multi-
factor methods of protecting my wallet.
Andy
--
Dr Andy Parkins
andyparkins at gmail.com
📝 Original message:On Tuesday 27 November 2012 17:14:19 Mike Hearn wrote:
> That's pretty much what we have today - in future other schemes can be
> proposed as extensions. Protocol buffers are easily extended, they
> ignore unknown fields. Then you'd wait and see what the invoice
> request looked like and produce an invoice with the right security
> bits.
That's good; I've not done anything with protocol buffers, so wasn't aware it
was that simple.
> > In particular two additional identification types:
> > - GnuPG (obviously)
>
> It's not obvious to me, incidentally. The web of trust has been
> dead-on-arrival since it was first proposed, and for good reasons.
> SSL/X.509, for better or worse, has significant usage.
Sorry, I meant "obviously" in the sense that "obviously that's the other one
that everyone will want". The web-of-trust as a universal identity mechanism
is, I agree, not useful. However, as a localised, smaller-scale identity
verification system it's used by every GnuPG user. You become your own
certificate authority. For example, I've set up my whole family with GnuPG;
I've set them up to trust me to authenticate (and I doubt any of them has ever
added anyone else). Then I take on the responsibility of signing all my
family/friends keys and they don't need to worry about it.
There's no reason that a small group of companies wouldn't do exactly the same
sort of thing.
> Your case of a small business is a perfect example of people who won't
> be using GPG. If they don't want to buy an SSL cert, they can just as
Bear in mind, I was using that example as an example of a hash protected in a
GPG envelope, not a GPG-signed invoice. People who've already got their GPG
system in place will appreciate being able to leverage it.
> well put a reference number in the memo field or a "Hey Bob, here is
> the bill we discussed". The payer does not get the multi-factor auth
How can they put a hash of an invoice inside the invoice? In my "hash mode"
invoices, it would be a random number (or possibly specifying the hash
algorithm) then the SignedInvoice would simply be the original invoice + hash.
That hash would then be reported via some secure channel outside of bitcoin's
domain.
> protection so if their computer has a virus, they may be hosed. But
> that's good incentive for sellers to get verified. Some CA authorities
> do it for free these days.
I don't understand what the relevance of multi-factor is to invoices? The
payment is performed via normal bitcoin mechanisms isn't it -- multi-factor or
not? This invoice system has one primary job: to ensure that the target of
the payment is who the payer thinks it is -- that's not affected by multi-
factor methods of protecting my wallet.
Andy
--
Dr Andy Parkins
andyparkins at gmail.com