Re: [w3c/webpayments-methods-tokenization] Generalisation of Encrypted Card (#22)

@mattsaxon,

Thanks to you and others for work on this. Here are some comments:

* It is not clear to me that that they key and signature should be part of the data object. I realize the goal is to leave PR API untouched, but that is a secondary priority IMO. I'd like to explore them as siblings to "data". 

* I understand the proposal to be about encryption of the response (e.g., due to phrases like "end to end encryption from the Payment App to the Payment Processor"). If so, it's not clear to me
what role plainData plays in the request. It is easier for me to envision this:

 {
    supportedMethods: "https://example.com/bobpay",
    data: { ...request data goes here...},
    responseEncryptionKey: {...key of merchant or processor...},
    returnUnencrypted: {property1, property2}
  }  

Or, if you want to group them:

 {
    supportedMethods: "https://example.com/bobpay",
    data: { ...request data goes here...}
    encryption: {
      responseEncryptionKey: {...key of merchant or processor...},
      returnUnencrypted: {property1, property2}
    }
  }  

Then the payment response could include property1 and property2 in **details** but no other
unencrypted properties. And, if encryption took place, **encryptedResponse** (which encrypts the entire **details**) would be present and a sibling of **details**. (Actually, we should clarify whether encryption is intended to be of the payment details or the entire PR API response.)

I am still thinking about the signature bits.

Thanks again!

Ian

-- 
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/webpayments-methods-tokenization/issues/22#issuecomment-347580183