W3C

Tokenization Task Force

29 May 2018

Agenda

Attendees

Present
Ian, stpeter, rick, Krystian, Roy, mattD, Ryan, Keyur, Ken
Regrets
Chair
Ian
Scribe
Ian

Contents


encryption spec

https://github.com/w3c/webpayments-crypto/blob/gh-pages/payment-encryption.md

https://github.com/w3c/webpayments-crypto/blob/wanli-patch-1/payment-encryption.md

Ian: I will turn into a spec

prototype next steps

https://www.w3.org/2018/Talks/ij_tokenization_20180515/token.pdf

IJ: Who would implement this spec and are they part of the conversation?

Ryan: My question is really around - whether the implementer needs to implement it for all card networks.
... eg., from MC we would only tokenize MC cards.

<Rick> q

IJ: I hear a question about whether the user experience is ok if, say, issuer only tokenizes a subset of (a network's) card

Richard: In some cases, merchant may not know whether they are getting a token or a PAN back
... we do need to distinguish "I know this is a token"

Ryan: There are 2 issues

- do we have the right mechanism to map the appropriate handler based on what the merchant says they accept

<Rick> q

scribe: or whether we need more granularity (e.g., issuer-level)

- how do we deal with knowing which card the user is attempting to add.

scribe: the enrollment case

Ryan: What is good payment handler behavior if the handler can't deal with the card?

Rick: 3 questions

- what's a token (in terms of data)

- what difference is there between the schemes (for that data)

- in what order of priority does the merchant want tokens

scribe: how does the merchant indicate a preference?
... does it want a schema token? an issuer token?

IJ: Is that use case one we need to be able to support?

Rick: I would assume merchant would want token that offers the most flexibility
... maybe we don't need to surface in this spec
... I don't think it will have a bearing on future use cases of the token

stpeter: Why would the merchant request a tokenized card?
... it seems it might want it for a variety of reasons (e.g., PCI)
... or are there other reasons (e.g., reuse) that are interesting?

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

IJ: If use case pref is important, should the merchant be able to provide a list of usage types (in order of preference) instead of just one?

stpeter: What do they want to accomplish (on the merchant side).

Rick: In addition to PCI, there are benefits like behavior in the face of compromised cards.
... I think the value proposition for the merchant is a separate topic

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

IJ: Anyone want to write up some benefits text?

<scribe> ACTION: Rick to check with Ken to see about proposing some text for the tokenization spec intro on benefits to various parties

<trackbot> Created ACTION-96 - Check with ken to see about proposing some text for the tokenization spec intro on benefits to various parties [on Rick Waller - due 2018-06-05].

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

Ryan: Suppose merchant says I want tokenized card and accept visa and mc.
... suppose the payment handler only does MC and the user tries to enter visa number.

<keyur> +q

stpeter: We've not figured out on firefox team yet how to implement payment handlers; chrome folks are not here today
... I think the question about who is the right payment handler and who is the fallback is potentially complex.

keyur: Is there a way to figure out whether the user wants to do an enrollment with a card
... so the user could say "I am paying with this type of card"
... suppose I am trying to enroll a card...I start on a merchant site
... suppose I click on a mc icon

IJ: You say "supportedNetwork: visa" (or similar) for a call just from that icon

Keyur: That would simplify the issue somewhat.
... The merchant controls the networks the merchant wants to display
... when a merchant accepts multiple card brands, the odds go up that the user will enter an improper card number in a payment handler
... I see only one way out - the payment handler throws and error and the merchant does a retry
... but if the user SELECTS the MC logo, the odds get better that the user will do the right thing

https://github.com/w3c/payment-request/issues/647

<Rick> Apologies, have to drop off. Cheers

IJ: The question is whether the retry would support a reduced set of payment methods, and whether the user experience would be better.

Ryan: I can imagine some network entities supporting some types of networks, and others doing multiple networks, and some saying "only from this issuer".

IJ: What breaks in the "only from this issuer"?

stpeter: Are we assuming the user wants to do tokenization?

Ian: No

Keyur: Going back to the question of software distribution, there is a possible that there is a payment handler that is basically just a routing mechanism
... it's a front end to capture the card but would integrate into multiple backends.
... once it has the data, then it can use any of them

IJ: Is that expected to be a rich ecosystem of providers?

Keyur: Might be browsers or networks

Stpeter: or issuers

Keyur: I would like to do some brainstorming about this.

stpeter: At mozilla we've also been discussing this from a strategic perspective.
... we are struggling with who will be deploying

token sharing use cases

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

Next call

12 June

Ian: I should have a draft encryption spec by then

Summary of Action Items

[NEW] ACTION: Rick to check with Ken to see about proposing some text for the tokenization spec intro on benefits to various parties
 

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2018/05/29 17:45:02 $