[w3c/webpayments-methods-tokenization] Token properties? (#25)

In reading the [current draft version](https://github.com/w3c/webpayments-methods-tokenization/wiki/Tokenized-Card), I notice that there are no constraints or communication flows about the properties of the returned payment token.

There are several ways that network tokens representing a card can differ:
- one time use v recurring use
- authorized only for specific amount v variable amounts
- chargeable only immediately or for any period of time in the future
- attached to a specific merchant or transaction type, etc.

Having the spec say nothing about the returned token seems like a problem. The worst case is that a merchant integrates against this method by testing with a few payment apps, only to discover later that some apps using the same method return tokens with radically different properties. They may end up having to tear out PRAPI integration since they can't control different payment apps returning different kinds of tokens for the same payment method.

To avoid this, it seems like there are two options:
1. Revise the spec to add in tokenization options or an extra communication path so the merchant/PSP can communicate information to the TSP.
2. Explicitly specify that returned tokens MUST have a very minimal utility: one-time use, for the specified total, etc. While this is less powerful and solves fewer use cases, it at least avoids semantic differences between apps implementing the spec.

-- 
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/25