Tokenization Task Force

<scribe> Scribe: Ian

--> https://lists.w3.org/Archives/Public/public-payments-wg/2018Jan/0018.html Agenda

Tokenization Spec next steps

https://github.com/w3c/webpayments-methods-tokenization/wiki/Tokenized-Card

https://github.com/w3c/webpayments-methods-tokenization/issues/25

Ian: Peter, any findings

stpeter: Look for review by end of day tomorrow.

https://github.com/w3c/webpayments-methods-tokenization/issues/25

Ian: Any feedback on Adam's comment?

sachin: I agree with the concern.
... I like the idea of providing a baseline (his option 2)

Peter: The security properties of tokens might need to be different if, e.g., 1-time v. recurring.
... attack surface might grow if the token persists.

IJ: Did we in fact think that the tokens might differ?

Sachin: I think that token representation will be the same, but the user perspective might differ.

Keyur: I think that as part of the tokenization spec maybe we should refer to how the token will be processed.
... we could give more details to the merchant/acquirer about how the token will be processed.
... the spec could refer to documentation of each network on how to process the token

<crallen> +q

Ken: Yes, makes sense to refer to documentation.

crallen: I think the question is "what kind of token is needed" v. "what kind of token is provided."
... to consider - there are 2 overarching models that are likely to be used.
... if you are requesting a token, are you requesting it as the owner of the token (you have a prior relationship with the TSP)
... v. you don't have a prior arrangement with the TSP, so the token will be bound by controls placed upon it.
... I think the information should flow in request as well as response.

IJ: Are links to documentation aggregated by EMVCo?

Clinton: Right now EMVCo does not. I think EMVCo is not the right place; not sure if W3C is the right place either.

Ian: any other reviewers want to take a look at this?

[No volunteers]

<scribe> ACTION: Sachin to respond to Adam's comment on GitHub

<trackbot> Created ACTION-77 - Respond to adam's comment on github [on Ahuja Sachin - due 2018-01-23].

Clinton: I will also review the spec.

alyver: General question - who do we see building payment handlers that support this? Issuers?

Deployment

alyver: From a customer perspective, how does an end customer discover this?

Ian: I have not anticipated customers caring; I think of this as data under the hood.
... Related - are browsers planning to implement this? I don't know

Sachin: Should we have flow diagrams?
... I think pictures will help in communication of the use cases.

https://w3c.github.io/webpayments-methods-tokenization/index.html

Sachin: I will take a stab at a sequence diagram.

https://w3c.github.io/webpayments-methods-tokenization/index.html#flow

Ian: Back to alyver's question - who will implement?

Peter: Mozilla is interested in implementation; need to check how it ranks with other priorities

Sachin: We have something in the works I believe.

Ken: Amex is interested; can't speak to timing.
... also check back with Facebook.

https://w3c.github.io/webpayments-methods-tokenization/index.html#flow

https://github.com/w3c/webpayments/wiki/Agenda-20180125

Ken: How does implementation get reflected back into the spec?

Ian: Via GitHub principally.

Visibility of tokenization in user experience

Ian: I imagine it being "under the hood". Do others agree it should not be very visible to the user?

Clinton: "Last four" should suffice.
... but in the future it might be useful for the user to know who the issuer is.

IJ: I imagine seeing issuer, eg. in choosing payment app.
... any other views on the importance of visibility of "you are doing tokenization" to the user?

Peter: We might want to see if there is any usability research regarding in-store flows.
... what do consumers feel like when they have a chip card v. mag stripe.

Ken: In Amex surveys, security is rated as "extremely important" so depending on messaging, highlighting that transactions are made more secure through tokenization could be a good thing.
... in some cases in the physical world, tokenization is unique to the device being used. To avoid user experience issues, it may be important to explain to cardholders that they choose with care which device they are using.
... issuers might get more than one card, and mixing and matching cards can create some user experience issues (e.g., around refunds)

Next meeting

23 January

Editor's note: Pushed to 30 January.