<scribe> Scribe: Ian
14 August
[Ian recaps the story]
- do token domain constraints affect payment handler (read; token requestor) matching?
- should any domain controls be merchant-centric?
Jonathan: Typically the merchant becomes the token requestor in card-on-file use case, to get a merchant-bound token (i.e., it can only be used for that merchant).
IJ: Could you set up the initial token so it is assigned to merchant not payment handler?
Jonathan: Merchant registration (with TSPs) is key in all use cases to ensure that credentials are provided to vetted merchants. It is possible to distinguish "registered merchant" from "merchant who has a backend integration with the TSP," i.e., registered merchants may not have a backend integration with TSP.
IJ: Does the merchant have to
have been registered before first call to PR API?
... should we add an assumption that merchants are registered
before getting first token?
... or could we expand PR API to support registration?
Jonathan: Let's look at registration separately
IJ: For use case #1 (where there are existing back end integrations)....how does it work?
Jonathan: Merchant swaps their token for a new token from the TSP that is dedicated to them....they become the token requestor.
IJ: For use case #2 (where there are not existing back end integrations), there are two flow ideas.
Jonathan: #2a - the browser only offers the same payment handler (or whoever is the original token requestor).
IJ: #2b - the browser offers any payment handler that is capable of reaching the same TSP.
Jonathan: This needs more review as it may present more flexibility but may be more complex or raise other security issues.
IJ: Use case #3- merchant says "card on file" in PR API when requesting the original token. The payment handler requests a token but tells the TSP to make the merchant the token requestor. Thus, when the merchant wants to request a future cryptogram, there is more flexibility in payment handlers because the domain control does not include the payment handler itself.
IJ: I could put together flow diagrams for these three flow.
https://github.com/w3c/webpayments-methods-tokenization/issues/45