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
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
https://github.com/w3c/webpayments-methods-tokenization/issues/41
12 June
Ian: I should have a draft encryption spec by then