[w3c/webpayments-methods-tokenization] Early Review Feedback (#26)

While reading through https://github.com/w3c/webpayments-methods-tokenization/wiki/Tokenized-Card as of 2018-01-16, I came across the following issues. Some of the editorial issues might be addressed when @ianbjacobs transforms this document with respec, but I figure it can't hurt to mention them.

1. There are no pointers to the relevant specifications (Basic Card, Payment Request, Payment Handler, RFC 2119, etc.).

2. Some of the RFC 2119 conformance language seems unnecessary (e.g., "Payment handlers MUST be able to access the services of one or more Token Service Providers."). Typically these terms are used when interoperability would be jeopardized by the lack of conformance, rather than for things like preconditions of implementation.

3. It's not clear what we mean by "EMV-like security". Does this mean we'd like to achieve a similar level of security while defining something that is entirely separate from the EMVco specifications? Or perhaps do we want to define something that is interoperable with EMV, i.e., a method that EMV implementations could use for communicating EMV payment tokens over the web?

4. It's not clear what we mean by "a BasicCard-like payment request flow". Does this mean the flow is nice and simple (like BasicCard), that it supplements or extends BasicCard, or something else entirely?

5. In the example, do we want to use a domain name that could be registered (pspKeyProvider.com) or is it safer to use an example domain (e.g., pspKeyProvider.example)?

6. Does the `methodData` argument shown here extend the `methodData` argument defined in the Payment Request specification (i.e., by adding a `keyProviderURL` field to the `PaymentMethodData` dictionary) or is it entirely separate? (See also comments below - a forward reference to the TokenizedCardRequest dictionary section might be helpful here.)

7. The code `const details = ...` could be filled in to provide more information.

8. With respect to the second and third bullet points in the Payment Method Properties section - where is the "add-card functionality" defined? A pointer would be helpful.

9. With respect to "Browsers MAY discover and install default payment handlers based on supportedNetworks." - isn't this true of any web payments implementation or specification? It doesn't seem that it needs to be called out in the tokenisation spec.

10. With respect to "Tokenized payment credentials MUST be encrypted." - this doesn't tell the reader (and especially the implementer) very much. Encrypted between which parties? Encrypted using what technologies? Is forward secrecy required? Is this transport security only (e.g., TLS) or also end-to-end object encryption? Etc.

11. With respect to "Token Service Providers MAY require KeyProviders to register/onboard." - register with a third-party service such a clearinghouse, with the Token Service Provider itself, or both? What is the purpose of such registration (e.g., so that the Token Service Provider can restrict its interactions to trusted entities)?

12. With respect to "Payment handler implementations MAY provide out-of-band provisioning functionality." - here too, a description of the purpose would be helpful to understand why this is mentioned.

13. If we expect that various payment method dictionaries will share data members - as this method shares `supportedMethods` and `supportedTypes` (*not* `supportedCardTypes` BTW) - does it make sense to define a reuse and extension mechanism instead of redefining these methods each time and saying that they are similar to the same members from other dictionaries? Defining the same thing in two different places never feels like a good idea...

14. The TokenizedCardRequest dictionary section says that keyProviderURL is "defined via the encryption specification", but then the next section defines it. :-)

15. The text in the TokenizedCardRequest dictionary section does not align with the diagram - for instance, the diagram uses the term Payment Handler, not Token Service Provider (but they seem to be the same thing).

16. The keyProviderURL section does not specific what public key formats are acceptable, any requirements around key length (etc.), and so on. It seems that some constraints would help us ensure interoperability.

17. There is no example of a TokenizedCardResponse, only of a TokenizedCardRequest (although it is not labelled as such). An example would be helpful.

18. The relationship between TokenizedCard and EncryptedTokenizedCard is not clear (probably because currently we're punting on the encryption methods). At least this should be called out. More specifically, we should more carefully define the various fields (especially cryptogram, typeOfCryptogram, eci, trid), describe why each one needs to be included as input to the encryption operation (at least that's what they seem to be, but it's unspecified), describe which ones are required and which ones are optional, etc.

19. From the perspective of the Tokenized Card Payment Method itself, it's probably OK to leave the "TokenizeCardRequest" (note the lack of a "d" there!) out of scope as something that needs to be defined by and agreed up between the Key Provider (a.k.a. Payment Handler) and Token Service Provider (a.k.a. Payment Network). However, we need to be very clear that true interoperability will require someone to define that flow (or flows), even if it's not the W3C.

20. It would be good to define the threat model here so that we can improve the security considerations. The authors might want to look at https://www.owasp.org/index.php/Threat_Risk_Modeling from OWASP or a similar document.

21. Do we really want to mention PCI scope here? At the least, it seems out of place for us to be using RFC 2119 conformance language here. (And "DO NOT" is not a conformance term.)

22. Overall, right now my impression is there's not quite enough detail (or too much ambiguity) here for people to build implementations, let alone interoperable implementations. In particular, punting on the encryption method (or methods) might make it actively irresponsible for someone to implement and deploy this specification as it stands. However, fixing these issues should be relatively straightforward. :-)

Thanks for listening.

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