IRC log of wpwg on 2017-05-23

Timestamps are in UTC.

15:30:02 [RRSAgent]
RRSAgent has joined #wpwg
15:30:02 [RRSAgent]
logging to http://www.w3.org/2017/05/23-wpwg-irc
15:30:05 [Ian]
zakim, clear agenda
15:30:05 [Zakim]
agenda cleared
15:30:11 [Ian]
Meeting: Tokenization Task Force
15:30:13 [Ian]
Chair: Ian
15:30:25 [Ian]
Agenda: https://lists.w3.org/Archives/Public/public-payments-wg/2017May/0057.html
15:31:20 [Ian]
present+ Ian
15:31:22 [Ian]
present+ alyver
15:31:25 [Ian]
present+ SteveSommers
15:31:29 [Ian]
present+ Christian
15:31:35 [Ian]
present+ ClintonAllen
15:31:55 [Ian]
present+ Olivier
15:32:12 [mweksler]
mweksler has joined #wpwg
15:32:22 [stan]
stan has joined #wpwg
15:32:37 [alyver]
alyver has joined #wpwg
15:32:37 [stan]
present+
15:32:49 [Ian]
present+ michel
15:32:52 [alyver]
present+ alyver
15:32:54 [Ian]
present+ Roy
15:33:31 [Ian]
topic: Stan's gathering of request/respnose data
15:33:36 [Ian]
https://docs.google.com/spreadsheets/d/1v1BPvR7Z7apBrxSNgTF-ifYJAvLEECYh7tHW-cpSUq4/edit#gid=0
15:33:53 [Ian]
stan: I catalogued different inputs/outpus
15:34:06 [Ian]
...comes with the caveat that I am not myself an expert in network tokenization
15:34:27 [ClintonA]
I am not able to access the spreadsheet...
15:34:28 [Ian]
...having said that, there is some uniformity
15:34:34 [Ken]
Ken has joined #wpwg
15:34:38 [Ian]
present+ Ken
15:36:39 [Ian]
stan: Major caveat...some of the gateways don't support a REST API publicly
15:37:04 [Ian]
..and stripe is moving toward not supporting tokenization through REST API publicly for PCI reasons...BUT moving to payment app would address that
15:37:20 [Ian]
....apple/masterpass/visa follow a similar pattern
15:37:29 [Ian]
...comes down to pre-agreed cert between merchant and PSP
15:38:06 [Ian]
...and output involves encrypted DPAN + cryptogram
15:38:16 [Ian]
...and when decrypted gives DPAN
15:38:37 [Ian]
...so gateways are pretty in alignment and the network-based are also aligned
15:38:40 [Ian]
q?
15:39:15 [Ian]
Manash: Apple pay => secure element. ...other cases can be cloud
15:39:34 [Ian]
...based on emvco standard, crypto can go into two fields
15:40:09 [alyver]
+1
15:40:39 [Ian]
Manash: PSP will have to mention the fields that they can take care of
15:40:59 [alyver]
q+
15:41:03 [Ian]
Stan: I am hearing that there's an input param from the merchant "what field acceptance"
15:41:07 [Ian]
Manash: Yes
15:41:11 [Ian]
...we can provide some more details later on
15:41:25 [Ian]
...we are working on an EMVCo summary to share with the group that will have more details
15:41:46 [Ian]
Stan: One interesting thing I noticed on Masterpass is that the request token needs to be created server side
15:41:57 [mweksler]
q+
15:42:08 [Ian]
Manash: Masterpass supports EMV token but we also support our own version of gateway tokens
15:42:16 [Ian]
...for merchants that want to reduce PCI exposure
15:42:21 [Ian]
..that leads to handshake
15:42:27 [Ian]
ack aly
15:42:36 [Ian]
s/+1//
15:42:53 [Ian]
alyver: The merchants also have the responsibility in some cases of putting data in the right fields
15:43:01 [Ian]
...in UCAP or some of the EMV fields
15:43:06 [Ian]
...so not just gateways
15:43:12 [Ian]
Manash: +1
15:43:15 [Ian]
ack m
15:43:24 [Ian]
q+ mweksler
15:43:35 [alyver]
s/UCAP/UCAF
15:43:37 [Ian]
clinton: This is my first call. Could someone describe the distinction between the two token types
15:43:54 [Ian]
stan: I think the gateway tokens have existed for a long time...simple goal of removing PCI scope for merchants
15:44:04 [Ian]
..the PAN is sent to the gateway server from the browser or payment app
15:44:16 [Ian]
...in exchange it will get a token..merchant will only get a token
15:44:36 [Ian]
....network tokens replace PAN with dynamic PAN with cryptogram
15:44:57 [Ian]
...so the former is motivated by PCI scope, the latter by security
15:45:00 [Ian]
https://github.com/w3c/webpayments-methods-tokenization/wiki
15:45:40 [Ian]
q?
15:45:59 [Ian]
Clinton: My role in EMVCo is chair of the tokenization WG
15:46:08 [Ian]
ack mw
15:46:28 [Ian]
mweksler: Thanks for the spreadsheet, Stan!
15:46:32 [Ian]
...great to be concrete.
15:46:52 [Ian]
..am I understanding the spreadsheet correctly...talking about payment app and the backend to which it connects
15:46:58 [Ian]
..is that the direction the spreadsheet was aimed at?
15:47:12 [Ian]
Stan: I think the goal was mostly to look at the interaction of the clients in both situations
15:47:36 [Ian]
...this is browser and payment app
15:47:55 [Ian]
mweksler: That requires find-tuning. E.g., I can take a picture of my credit card to add to Apple Pay
15:48:12 [Ian]
..there's a client that consumes the PAN and then somehow turns it into a token
15:48:12 [alyver]
What you are describing is the provisioning of the card in the "wallet"
15:48:24 [Ian]
...we may need to add another column for "user agent" mechanism
15:48:32 [Ian]
....we may need to clarify what we mean by client
15:48:47 [Ian]
Stan: I think that makes sense...the spreadsheet was focused on the client side library requirements
15:48:53 [Manash_MC]
Manash_MC has joined #WPWG
15:49:02 [Manash_MC]
+1
15:49:03 [ClintonA]
q+
15:49:27 [Ian]
ack Cli
15:50:04 [Ian]
ClintonA: What you are highlighting here is associating a plastic card with a wallet is provisioning, which is decoupled from the transaction step
15:50:21 [Ian]
mweksler: I think we still need to address them both (provisioning, usage)
15:50:44 [Ian]
...I think there is similarity in use, and deviation in provisioning
15:50:54 [Ian]
manash: Tokenization, provisioning, transaction
15:52:25 [Ian]
Stan: Gateway transactions are a representation of a card. They can be used or reused to create transactions.
15:52:47 [Ian]
...whether network tokens, due to their single-use flavor (mostly true but not always) mostly represent a transaction, though in some cases you can create subsequent charges using them
15:52:49 [ClintonA]
q+
15:53:14 [Ian]
...Stripe creates a token, you can do a charge with the token and used for future charges
15:53:16 [alyver]
q+
15:54:08 [Ian]
ack clin
15:54:20 [Ian]
IJ: I am hearing properties ... should we document?
15:54:36 [Ian]
ClintonA: Gateway tokens are generally identified within an ecosystem (e.g., a braintree token is for that ecosystem)
15:54:43 [Ian]
..network tokens can be shared across multiple merchants/gateways
15:54:54 [Ian]
..which highlights another distinguishing quality - they can exist without a cryptogram
15:55:14 [Ian]
..when you introduce token+cryptogram creates a transactional combination
15:55:40 [Ian]
..within the gateway space, each token is unique to an ecosystem and may not be used in a transaction
15:55:51 [Ian]
...network protects transaction outside the acquiring space
15:56:16 [Ian]
roy: While things like "publishable key" and "merchant id" sound similar, they are different values by gateway
15:56:20 [shift4sms]
q+
15:56:37 [Ian]
...you don't get to reuse keys...which says to me each gateway might want its own PMI
15:56:39 [Ian]
ack aly
15:56:58 [Ian]
alyver: There was a comment earlier about gateway/network tokens behaving the same way once in the system...for network tokens there's a provisioning step
15:57:23 [Ian]
...at that point stored in my wallet...then when I do a transaction, the encrypted payload is returned to the merchant who decrypted
15:57:56 [Ian]
...in the case of a gateway token (I am thinking Android Pay / Chrome implementation of PR API).....gateway tokenization happens with downstream PSP and merchant gets back a gateway token
15:58:05 [Ian]
...I'm not sure if we are also considering that flow
15:58:14 [Ian]
ack shif
15:58:20 [Ian]
q+ mweksler
15:58:30 [stan]
q+
15:58:46 [Ian]
steve: Regarding reuse of gateway tokens...not sure you can lump them all together. Our gateway has 2 forms of tokens in our API process...
15:58:51 [Ian]
...whether single or multi use toikens
15:58:54 [Ian]
s/toikens/tokens
15:59:07 [Ian]
...gateways can to multi-use tokens...not sure you can generalize the distinction
15:59:24 [Ian]
...to me the only really diff between the two is that a gateway token can't really be used in a wallet scenario
15:59:36 [Ian]
...not generally reusable
15:59:48 [Ian]
...other than that, the features can be mixed and matched
16:00:04 [Ian]
mweksler: that's fair. Gateway tokens are "scoped" to the merchant that they were added under
16:00:19 [Manash_MC]
Manash_MC has joined #WPWG
16:00:31 [Ian]
...if I add a card through a web site and I use stripe as a PSP, I get back a token that is scoped to that site and I can't use with another site even though I am same user, might be same PSP, etc.
16:00:36 [Ian]
...that is definitely a difference.
16:00:45 [ClintonA]
+q
16:00:47 [Manash_MC]
+1
16:00:58 [Ian]
...in terms of similarities, if we look at PR API, and say there is a tokenized payment handler
16:01:22 [oyiptong]
q+ gateway tokens + wallets
16:01:26 [Ian]
...and we do some enrollment (let's put aside that for a moment), at that point, I get a token and payment handler is responsible for handing the right token back to the browser
16:01:37 [Ian]
..that was the seemingly appealing similarity between the two approaches
16:01:39 [Ian]
ack mweksler
16:01:55 [Ian]
...it does feel appealing to me - you have the same interaction regardless of gateway or network token
16:01:56 [oyiptong]
err, i messed up the queue, sorry, Ian
16:02:00 [Ian]
q?
16:02:04 [Ian]
ack stan
16:02:09 [Manash_MC]
q+
16:02:18 [Ian]
queue==ClintonA, oyiptong, Manash
16:02:46 [Ian]
(Suggest columns: "encrypted?" "scoped?"
16:02:57 [Ian]
stan: gateways have integrated with network tokenization solutions in many ways
16:03:11 [Ian]
..even if we were to layer the two systems one on another, it would probably not be compatible with thew ays
16:03:19 [Ian]
....that gateways get those tokens today
16:03:37 [Ian]
...and so it feels like even if we wanted to layer systems to get a unified tokenized API it would nonetheless create complexity
16:03:59 [Ian]
...we've been discussing internally at Stripe....current thinking is that it would be complex
16:04:26 [Ian]
...feels complex to abstract all tokenization aspects
16:04:37 [Ian]
....gateways expect network tokens today in non-standard ways
16:05:12 [Ian]
q?
16:05:14 [Ian]
ack Cli
16:05:32 [Ian]
ClintonA: Some of the language that I hear now is that network tokens do not have a common way of requesting/receiving tokens
16:05:37 [Ian]
...that's helpful feedback for me
16:06:28 [Ian]
...one of the things I'd like to clarify: when we look at token types...I think the problem to solve is "if you have a wallet that needs to store a cardholder's credentials, if you use a gateway token, that wallet scope is limited to the gateway..but if you use a network token, can be reused independent of gateway"
16:06:42 [Ian]
...I hear the problem being how to reuse a token across merchants/acquirer
16:06:47 [shift4sms]
q+
16:07:28 [shift4sms]
q-
16:08:04 [Ian]
ack oy
16:08:40 [Ian]
oyiptong: Thanks for the spreadsheet. I'd like to touch on something Steve said...he was saying that network tokens be stored in a wallet but gateway tokens cannot...I don't think that's quite accurate. I think we could store gateway tokens by origin
16:09:01 [Ian]
...so while it's true that gateway tokens are scoped to PSP and merchant, but in a wallet you could store it for a specific (merchant) origin.
16:09:23 [shift4sms]
+1
16:09:24 [Ian]
...for example, foo.com uses gateway token could be stored in my wallet specifically for Stripe+foo.com
16:09:51 [Ian]
...but it is true that we lose interop in the sense that "same PAN cannot be reused on another origin even if they use the same PSP"
16:10:21 [Ian]
...if we lived in a world where network tokens were the norm, we wouldn't need gateway tokens, but you'd still have the problem of storing token in wallet based on network used
16:10:22 [Ian]
q?
16:10:25 [Ian]
ack Ma
16:10:58 [Ian]
Manash: From the merchant perspective (or whoever is invoking PR API)...if I am merchant or say worldpay...what is the difference in terms of options
16:11:10 [Ian]
....can that be standardized so that merchant does not have to create different options
16:11:14 [Ian]
...that is one thought
16:11:34 [Ian]
..the second is ... the response to the merchant...can that response be in a standard format independent of token type
16:13:08 [Ian]
Stan: If we look at what the user wants - an easy way to do multi-gateway tokenization without needing a central vault
16:13:14 [Ian]
...that can be provided for outside of this effort
16:13:37 [Ian]
...an alternative is to address network tokenization clearly today
16:14:22 [Ian]
mweksler: I want to mention a few things from our perspective...I am sure we agree we want to make it easy for users ...but from a merchant perspective, we already have the pipes that are mentioned in the spec (tokenizing things from the browser using PSPs)...but we need multiple integrations
16:14:26 [Ian]
...this standard would just be one of those
16:14:46 [Ian]
...network tokenization at the moment requires a lot of ceremony before it can be used..e.g., redirecting the user
16:14:50 [stan]
q+
16:14:52 [Ian]
...a lot of steps are required
16:14:57 [Ian]
..but that means more friction
16:15:17 [Ian]
..I think that is perhaps the single most difficult aspect of the network tokenization schemes I've seen -- multiple steps to onboard a user.
16:15:26 [Ian]
..but in the end they result to something that is very similar to the gateway tokens
16:15:47 [ClintonA]
+q
16:15:51 [Ian]
...the merchant wants to process something, it gives a token to its integrated PSPs and the transaction goes through.
16:16:13 [Ian]
..if we focus on that, and reduce the complexity stan refers to (and hide from users) we could come up with something easy to use and never requires merchants to see a PAN
16:16:14 [Ian]
ack stan
16:16:31 [Ian]
stan: I strongly agree on the goal of making using network tokenization easier with less integration for merchants
16:16:49 [Ian]
..but having one single client side integration is an orthogonal goal and we can sequence them
16:17:02 [Ian]
...could start with network and then build a layer on top to solve multiple merchant integrations
16:17:10 [Ian]
...trying to solve all in one go makes it easier
16:17:20 [Ian]
mweksler: Why start with network tokenization over gateway?
16:17:51 [Ian]
stan: they are 2 different beasts...one is user interaction in user agent that generates a token (that's network). Whereas gateway tokenization is a representation of a card.
16:18:13 [Ian]
...we can standardized the APIs for network tokenization (redirect based)...and once we get there, we can do gateway
16:18:19 [mweksler]
q+
16:18:30 [Ian]
..there are also other payment methods (beyond cards) to look at
16:18:52 [Ian]
...I think focusing on network tokens will reduce the problem space and then we can sequence...that's our current take
16:19:00 [Ian]
..I am hearing other takes as well
16:19:02 [Ian]
ack Cl
16:19:53 [Ian]
ClintonA: I think that choosing gateway v. network is likely to be the wrong approach. I think that both types provide value. I think network tokens provide value where gateway tokens cannot ... security features outside of acquirer
16:20:05 [Ian]
...I think layering the systems on one another would be helpful
16:20:15 [Ian]
...but there are complexities
16:20:17 [Ian]
ack mweksler
16:20:31 [Ian]
mweksler: I wanted to take the two previous points and wrap them into the larger context of the other specs in play
16:20:46 [Ian]
...by the way, I'd love to get a spec around network tokens; I agree it's a good idea...
16:21:01 [Ian]
..but I think one of the reasons we started to look at gateway tokens has to do with the current state of the specs
16:21:10 [Ian]
...Basic Card has PANs flowing freely between browser and merchant
16:21:51 [Ian]
...a few of us felt that Basic Card was a reasonable way to start, but we need to fast forward to increasing security, does not expose merchant to PCI Scope
16:21:59 [shift4sms]
q+
16:22:03 [Ian]
..so an idea was "encrypt in the browser" and flow through existing channels
16:22:04 [Ian]
q+
16:22:24 [Ian]
mweksler: one way to look at sequencing is that gateway tokens seem to provide an easier next step
16:22:39 [Ian]
Roy: I am hearing a lot of comments around network tokenization v. gateway..if you look at the current draft spec
16:22:46 [Ian]
..it is very network-token oriented
16:22:59 [Ian]
...maybe we can take the learnings from today and see how relates to existing text
16:23:03 [Manash_MC]
+q
16:23:13 [Ian]
...specifically around gateway tokens, does it make sense to look at a spec around gateway tokens?
16:23:15 [Ian]
ack shif
16:23:56 [Ian]
shift4sms: A lot of the discussion seems to be pulling some of the feature set of gateway and merging with some of the feature set of networks. A lot of features cross over...but network tokens for a majority of their usage today is single-use (there are exceptions)
16:24:03 [ClintonA]
+q
16:24:06 [Ian]
...the gateway tokens are typically more for multi-use
16:24:40 [Ian]
...we are talking about "merging" but keep in mind that once you start to make a gateway more reusable across merchants, you need to make sure we are not merely replacing sensitive information with more sensitive informaiton
16:24:47 [Ian]
ack me
16:27:39 [Ian]
IJ: Should we have parallel activities to see how similar the two approaches look in practice?
16:27:44 [mweksler]
+1 on articulating as two parallel proposals
16:27:48 [ClintonA]
q-
16:27:56 [Ian]
Manash: I think we may need additional merchants to hear their needs
16:28:34 [Ian]
...EMVCo has worked hard to create a token format that works across a lot of stakeholders and we should leverage that
16:29:02 [Ian]
...we should probably get input from merchants (even outside of W3C) and get their feedback on the two tokenization approach
16:29:03 [Ian]
q?
16:29:05 [Ian]
ack Man
16:30:13 [mweksler]
happy to help Stan
16:30:27 [Ian]
ACTION: Stan will take another pass on the spreadsheet to shed light on categories / similarities
16:30:27 [trackbot]
Error finding 'Stan'. You can review and register nicknames at <http://www.w3.org/Payments/WG/track/users>.
16:31:34 [Ian]
IJ: Are parallel efforts responsive to Stripe perspectie?
16:32:06 [Ian]
Stan: Taking our understanding, simplifying network tokenization was for us "most urgent and efficient"
16:32:13 [Ian]
...so that aligns with current state of spec
16:32:43 [oyiptong]
q+
16:33:12 [Ian]
IJ: Any interest for Airbnb + MasterCard to attack gateway spec?
16:33:15 [Ian]
ack oyiptong
16:33:23 [Ian]
oyiptong: It might be good to think about Airbnb to work on both
16:33:56 [Ian]
....if stan's right and network is an easier way to start....worth it for us to think about both
16:34:06 [Ian]
...or michel on network and me on gateway
16:34:17 [Ian]
Manash: I can work with folks on gateway tokens as well
16:34:58 [alyver]
I'm happy to participate in the network token discussion.
16:36:52 [Ian]
IJ: Roy are you still lead on the network side?
16:37:17 [Ian]
Roy: yes
16:37:25 [oyiptong]
+1
16:37:56 [Ian]
IJ: Olivier and Manash work out who takes lead for gateway
16:38:09 [Ian]
Manash: I think we should organize a demo of how network tokens work
16:38:37 [Ian]
IJ: Any update on updated flow diagram?
16:38:46 [Ian]
Manash: I will check
16:38:46 [Ian]
Topic: next meeting
16:38:56 [ClintonA]
q+
16:38:59 [Ian]
ack clin
16:39:27 [Ian]
ClintonA: As you pointed out, I am hear with Amex affiliations but also participate in EMV in tokenization, remote commerce
16:39:31 [Ian]
..happy to be part of conversations
16:40:15 [Ian]
Next meeting: 6 June
16:40:18 [mweksler]
+1
16:40:18 [oyiptong]
+1
16:40:27 [Ian]
...and in the meantime we will work to advance the gateway story
16:40:43 [Ian]
RRSAGent, make minutes
16:40:43 [RRSAgent]
I have made the request to generate http://www.w3.org/2017/05/23-wpwg-minutes.html Ian
16:40:48 [Ian]
RRSAGent, set logs public
16:47:53 [Ian]
RRSAGent, make minutes
16:47:53 [RRSAgent]
I have made the request to generate http://www.w3.org/2017/05/23-wpwg-minutes.html Ian
16:47:56 [Ian]
RRSAGent, set logs public
17:03:40 [betehess]
betehess has joined #wpwg
17:05:14 [cweiss]
cweiss has joined #wpwg
17:49:34 [cweiss]
cweiss has joined #wpwg
17:55:34 [cweiss]
cweiss has joined #wpwg
18:03:58 [stan]
stan has joined #wpwg
18:04:20 [alyver]
alyver has joined #wpwg
18:15:12 [alyver]
alyver has joined #wpwg
18:19:23 [stan]
stan has joined #wpwg
18:28:25 [stan]
stan has joined #wpwg
18:53:15 [betehess]
betehess has joined #wpwg
19:07:36 [cweiss]
cweiss has joined #wpwg
19:13:51 [cweiss]
cweiss has joined #wpwg
19:15:21 [Zakim]
Zakim has left #wpwg
20:16:07 [stan]
stan has joined #wpwg
20:47:14 [cweiss]
cweiss has joined #wpwg
21:25:06 [stan]
stan has joined #wpwg
21:29:36 [stan]
stan has joined #wpwg
22:06:58 [cweiss]
cweiss has joined #wpwg
22:24:27 [stan]
stan has joined #wpwg
22:56:26 [cweiss]
cweiss has joined #wpwg
23:03:59 [stan]
stan has joined #wpwg
23:07:56 [stan]
stan has joined #wpwg
23:12:10 [stan]
stan has joined #wpwg
23:33:56 [stan]
stan has joined #wpwg
23:40:25 [stan]
stan has joined #wpwg
23:43:58 [stan]
stan has joined #wpwg
23:54:08 [stan]
stan has joined #wpwg
23:55:47 [cweiss]
cweiss has joined #wpwg