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

Peter.

Thanks immensely for the close review. Below I've catalogued my responses:

* I made some changes to the wiki (with change notes) and plan to make others
to the spec when I port the text over.
* I tried to answer a couple of the points (but no changes required, it seemed to me).
* The remaining points are good ones for task force discussion, so I will put them on the agenda of the group's next call.

Ian

================================
Seeking comment from the task force

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?

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.

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.

   COMMENT: I'd love help with this.

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.

===================================
Ian endeavors to answer; no changes

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?

  Ian: I don't think that it extends it. I think that the "data"
       member is payment-method-specific.

7. 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.

  Ian: Add card functionality would not (I believe) be defined
       in a W3C spec. One way to handle your observation would
       be to add a FAQ question, such 


================================
Made these changes in the wiki

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)?

   CHANGE: Used pspKeyProvider.example

6. (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.

   CHANGE: Copied 'detals' example from PR API.

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.

   CHANGE: "Add card" functionality is not in scope of this
   specification. I have (for now) created a new FAQ question "How
   will users add and remove payment instruments to the payment
   handler?"  My expectation is that this would end up in the Web
   Payments FAQ [1] and not in the spec. (I have not yet moved it to
   the FAQ while we get feedback.)

  [1] https://github.com/w3c/payment-request-info/wiki/FAQ

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.

   CHANGE: Added another FAQ question "Can browsers discover and
   install default payment handlers based on supportedNetworks?" with
   a link to the Payment Handler API issue on that topic.


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

   CHANGE: Removed the comment. (The actual definition may also
   need attention.)

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.)

   CHANGE: Moved to a FAQ question. Also edited the text to make
   clearer that the WPWG does not (and should not IMO) have a
   formal position on the question. I rephrased some of the
   sentences as WG assumptions; I'd like us to verify these
   with PCI.

   We already have two PCI entries in our FAQ:
   https://github.com/w3c/payment-request-info/wiki/FAQ#how-does-payment-request-api-affect-pcidss-compliance

   It would make sense to me to add this one as well, once it
   matures.


================================
Plan to make these changes when
ported to the specification

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

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...

  COMMENT: I agree. I am not fluent enough in WebIDL to include
  by reference; I will seek help on how to do that. I am hoping
  that that because we want to reuse the entire BasicCardRequest
  dictionary this will be straightforward. 

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).

  COMMENT: I plan to fix the diagram.

-- 
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#issuecomment-359096776