Re: [w3c/browser-payment-api] How are digital signatures supported for Payment Requests? (#291)

> What's the motivation to sign the whole request and not just provide the signature in the payment method specific data?

Signing the whole request is simpler in at least these ways:

1. Cognitive load on developers is reduced greatly. Either the request is signed or not. If it's signed, all data is protected.
2. Attack surface is reduced. Either the entire request is signed or it's not. If the entire request is signed, it's easier to understand the attack surface on payment request messages.
2. No extra digital signature construction algorithms are required.
3. All payment requests are protected, not just certain payment methods that support digital signatures.

There are some downsides:

1. Merchant payment method privacy is "violated", but as explained above, it's arguable that we can protect merchant payment method privacy in the vast majority of cases.
2. We'd have to provide a single argument option to the PaymentRequest constructor.

There are two options as far as I can see wrt. digital signatures on payment requests (there may be more):

1. Create a new digital signature algorithm that builds a document that you can then digitally sign and then put that digital signature in the payment method's 'data' object.
2. Create a one parameter option to the Payment Request constructor that enables you to feed in an object that looks something like this: https://github.com/w3c/browser-payment-api/issues/291#issuecomment-253229863 and ensure that object is what's serialized and sent to the payment app.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/browser-payment-api/issues/291#issuecomment-253809187