search

bitpay / jsonPaymentProtocol

JSON Payment Protocol Interface
46 stars 58 forks source link

Auth is a regression over current Bip70 #18

Closed cpacia closed 5 years ago

cpacia commented 5 years ago

As I understand the way the user is expected to authenticate is to manually search the internet for the GPG key, somehow download it from a trusted source (in practice this will almost always amount to downloading in the clear over the internet), and then manually import in the wallet.

This is a clear regression over Bip70. The point of the X509 certs, while cumbersome, was to remove the need to do the above and to allow people to validate the cert against a known certificate authority without searching for a known trusted source.

If you want to make authentication easier you could simply require SSL and require that the SSL cert used to serve the payment request be the identity the merchant desires to use.

This would make identity handling pretty easy. For example:

resp, _ := http.Get("https://bitpay.com")
org := resp.TLS.PeerCertificates[0].Subject.Organization[0]
cn := resp.TLS.PeerCertificates[0].Subject.CommonName
fmt.Printf("Do you want to send a payment to %s(%s)?", org, cn)

But the current proposal to manually find verify GPG keys would be a non-starter for me. The result would be everyone just hardcodes bitpay's GPG key and the payment protocol is only usable to pay bitpay and nobody else.

unusualbob commented 5 years ago

If you want to rely solely on x509 you can verify the TLS session the request itself, as all bitpay requests are sent over https. We wanted to allow a way for wallets to verify the payment request without having to add libraries just for dealing with x509. This is also why we used secp256k1 so it would be the exact same crypto used for bitcoin transactions. We figured most wallets would either bake in the ecc public key, or as many wallets rely on a web API, provide an endpoint of verified ecc public keys.