Re: [w3c/payment-method-basic-card] add: User changes payment method section (#53)

marcoscaceres commented on this pull request.



> +          The <dfn>steps for when a user changes payment method</dfn> are as
+          follows:
+        </p>
+        <ol>
+          <li>From the <a>supported cards</a> presented to the end-user, let
+          <var>card</var> be the <a>card</a> the user selected.
+          </li>
+          <li>Let <var>methodDetails</var> be a newly created
+          <a>BasicCardChangeDetails</a> dictionary.
+          </li>
+          <li>Set <var>methodDetails</var>["<a>type</a>"] to the
+          <a>BasicCardType</a> that represents <var>card</var>'s <a>type</a>.
+          </li>
+          <li>If the <var>card</var> is part of a <a>network</a>, set
+          <var>methodDetails</var>["<a>network</a>"] to the network identifier
+          that represents <var>card</var>'s <a>network</a>

@mnoorenberghe, wrote: 
>  If the merchant wants to do anything meaningful with this data (e.g. to change the total and replace the need for modifiers) then the UA would have to dispatch this event as soon as the PaymentRequest opens and that would leak the user's default-selected type and network to the merchant. 

We discussed this at the F2F also. The solution is to apply the modifiers on `show()`, then no event is fired on the default card - the modified gets applied,  so no leakage occurs immediately. 

When the user then changes card, by actually clicking on it, then we would fire the event. 

I'll clarify that the event should only fire on explicit user action. 

> It sounds like Apple didn't send the network with their applepaypaymentmethodchanged event either so I'm not sure the network is needed. 

I was reaching the same conclusion... why I started `null`'ing it out :) I'll remove it. 

> Because of the increased fingerprinting potential (type + network) from a user-interaction showing a PR without the user completing it, I no longer like the idea of the event, especially if the network is leaked (since it provides more entropy). 
 
With the removal of network, and not firing on default card, I think the above is sufficient to mitigate the privacy risks, no?  

(note also that you can `.canMakePayment()` this information already, but we can deal with that separately.) 

@stpeter wrote:
> I'm not sure what these display items are, but presumably they are not new items in the cart but actually payment modifiers

The idea is that if you know the card type, you don't need the modifiers on subsequent changes. So, instead of having a modifier, the developer just updates the display items directly.     


-- 
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/payment-method-basic-card/pull/53#discussion_r187230326