Tokenization Task Force

Stan's gathering of request/respnose data

https://docs.google.com/spreadsheets/d/1v1BPvR7Z7apBrxSNgTF-ifYJAvLEECYh7tHW-cpSUq4/edit#gid=0

stan: I catalogued different inputs/outpus
... comes with the caveat that I am not myself an expert in network tokenization

<ClintonA> I am not able to access the spreadsheet...

stan: having said that, there is some uniformity
... Major caveat...some of the gateways don't support a REST API publicly
... and stripe is moving toward not supporting tokenization through REST API publicly for PCI reasons...BUT moving to payment app would address that
... apple/masterpass/visa follow a similar pattern
... comes down to pre-agreed cert between merchant and PSP
... and output involves encrypted DPAN + cryptogram
... and when decrypted gives DPAN
... so gateways are pretty in alignment and the network-based are also aligned

Manash: Apple pay => secure element. ...other cases can be cloud
... based on emvco standard, crypto can go into two fields
... PSP will have to mention the fields that they can take care of

Stan: I am hearing that there's an input param from the merchant "what field acceptance"

Manash: Yes
... we can provide some more details later on
... we are working on an EMVCo summary to share with the group that will have more details

Stan: One interesting thing I noticed on Masterpass is that the request token needs to be created server side

Manash: Masterpass supports EMV token but we also support our own version of gateway tokens
... for merchants that want to reduce PCI exposure
... that leads to handshake

alyver: The merchants also have the responsibility in some cases of putting data in the right fields
... in UCAF or some of the EMV fields
... so not just gateways

Manash: +1

clinton: This is my first call. Could someone describe the distinction between the two token types

stan: I think the gateway tokens have existed for a long time...simple goal of removing PCI scope for merchants
... the PAN is sent to the gateway server from the browser or payment app
... in exchange it will get a token..merchant will only get a token
... network tokens replace PAN with dynamic PAN with cryptogram
... so the former is motivated by PCI scope, the latter by security

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

Clinton: My role in EMVCo is chair of the tokenization WG

mweksler: Thanks for the spreadsheet, Stan!
... great to be concrete.
... am I understanding the spreadsheet correctly...talking about payment app and the backend to which it connects
... is that the direction the spreadsheet was aimed at?

Stan: I think the goal was mostly to look at the interaction of the clients in both situations
... this is browser and payment app

mweksler: That requires find-tuning. E.g., I can take a picture of my credit card to add to Apple Pay
... there's a client that consumes the PAN and then somehow turns it into a token

<alyver> What you are describing is the provisioning of the card in the "wallet"

mweksler: we may need to add another column for "user agent" mechanism
... we may need to clarify what we mean by client

Stan: I think that makes sense...the spreadsheet was focused on the client side library requirements

<Manash_MC> +1

ClintonA: What you are highlighting here is associating a plastic card with a wallet is provisioning, which is decoupled from the transaction step

mweksler: I think we still need to address them both (provisioning, usage)
... I think there is similarity in use, and deviation in provisioning

manash: Tokenization, provisioning, transaction

Stan: Gateway transactions are a representation of a card. They can be used or reused to create transactions.
... 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
... Stripe creates a token, you can do a charge with the token and used for future charges

IJ: I am hearing properties ... should we document?

ClintonA: Gateway tokens are generally identified within an ecosystem (e.g., a braintree token is for that ecosystem)
... network tokens can be shared across multiple merchants/gateways
... which highlights another distinguishing quality - they can exist without a cryptogram
... when you introduce token+cryptogram creates a transactional combination
... within the gateway space, each token is unique to an ecosystem and may not be used in a transaction
... network protects transaction outside the acquiring space

roy: While things like "publishable key" and "merchant id" sound similar, they are different values by gateway
... you don't get to reuse keys...which says to me each gateway might want its own PMI

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
... at that point stored in my wallet...then when I do a transaction, the encrypted payload is returned to the merchant who decrypted
... 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
... I'm not sure if we are also considering that flow

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...
... whether single or multi use tokens
... gateways can to multi-use tokens...not sure you can generalize the distinction
... to me the only really diff between the two is that a gateway token can't really be used in a wallet scenario
... not generally reusable
... other than that, the features can be mixed and matched

mweksler: that's fair. Gateway tokens are "scoped" to the merchant that they were added under
... 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.
... that is definitely a difference.

<ClintonA> +q

<Manash_MC> +1

mweksler: in terms of similarities, if we look at PR API, and say there is a tokenized payment handler
... 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
... that was the seemingly appealing similarity between the two approaches
... it does feel appealing to me - you have the same interaction regardless of gateway or network token

<oyiptong> err, i messed up the queue, sorry, Ian

(Suggest columns: "encrypted?" "scoped?"

stan: gateways have integrated with network tokenization solutions in many ways
... even if we were to layer the two systems one on another, it would probably not be compatible with thew ays
... that gateways get those tokens today
... and so it feels like even if we wanted to layer systems to get a unified tokenized API it would nonetheless create complexity
... we've been discussing internally at Stripe....current thinking is that it would be complex
... feels complex to abstract all tokenization aspects
... gateways expect network tokens today in non-standard ways

ClintonA: Some of the language that I hear now is that network tokens do not have a common way of requesting/receiving tokens
... that's helpful feedback for me
... 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"
... I hear the problem being how to reuse a token across merchants/acquirer

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

<shift4sms> +1

oyiptong: for example, foo.com uses gateway token could be stored in my wallet specifically for Stripe+foo.com
... 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"
... 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

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
... can that be standardized so that merchant does not have to create different options
... that is one thought
... the second is ... the response to the merchant...can that response be in a standard format independent of token type

Stan: If we look at what the user wants - an easy way to do multi-gateway tokenization without needing a central vault
... that can be provided for outside of this effort
... an alternative is to address network tokenization clearly today

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
... this standard would just be one of those
... network tokenization at the moment requires a lot of ceremony before it can be used..e.g., redirecting the user
... a lot of steps are required
... but that means more friction
... I think that is perhaps the single most difficult aspect of the network tokenization schemes I've seen -- multiple steps to onboard a user.
... but in the end they result to something that is very similar to the gateway tokens

<ClintonA> +q

mweksler: the merchant wants to process something, it gives a token to its integrated PSPs and the transaction goes through.
... 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

stan: I strongly agree on the goal of making using network tokenization easier with less integration for merchants
... but having one single client side integration is an orthogonal goal and we can sequence them
... could start with network and then build a layer on top to solve multiple merchant integrations
... trying to solve all in one go makes it easier

mweksler: Why start with network tokenization over gateway?

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.
... we can standardized the APIs for network tokenization (redirect based)...and once we get there, we can do gateway
... there are also other payment methods (beyond cards) to look at
... I think focusing on network tokens will reduce the problem space and then we can sequence...that's our current take
... I am hearing other takes as well

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
... I think layering the systems on one another would be helpful
... but there are complexities

mweksler: I wanted to take the two previous points and wrap them into the larger context of the other specs in play
... by the way, I'd love to get a spec around network tokens; I agree it's a good idea...
... but I think one of the reasons we started to look at gateway tokens has to do with the current state of the specs
... Basic Card has PANs flowing freely between browser and merchant
... 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
... so an idea was "encrypt in the browser" and flow through existing channels
... one way to look at sequencing is that gateway tokens seem to provide an easier next step

Roy: I am hearing a lot of comments around network tokenization v. gateway..if you look at the current draft spec
... it is very network-token oriented
... maybe we can take the learnings from today and see how relates to existing text

<Manash_MC> +q

Roy: specifically around gateway tokens, does it make sense to look at a spec around gateway tokens?

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)

<ClintonA> +q

shift4sms: the gateway tokens are typically more for multi-use
... 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

IJ: Should we have parallel activities to see how similar the two approaches look in practice?

<mweksler> +1 on articulating as two parallel proposals

Manash: I think we may need additional merchants to hear their needs
... EMVCo has worked hard to create a token format that works across a lot of stakeholders and we should leverage that
... we should probably get input from merchants (even outside of W3C) and get their feedback on the two tokenization approach

<mweksler> happy to help Stan

<scribe> ACTION: Stan will take another pass on the spreadsheet to shed light on categories / similarities [recorded in http://www.w3.org/2017/05/23-wpwg-minutes.html#action01]

<trackbot> Error finding 'Stan'. You can review and register nicknames at <http://www.w3.org/Payments/WG/track/users>.

IJ: Are parallel efforts responsive to Stripe perspectie?

Stan: Taking our understanding, simplifying network tokenization was for us "most urgent and efficient"
... so that aligns with current state of spec

IJ: Any interest for Airbnb + MasterCard to attack gateway spec?

oyiptong: It might be good to think about Airbnb to work on both
... if stan's right and network is an easier way to start....worth it for us to think about both
... or michel on network and me on gateway

Manash: I can work with folks on gateway tokens as well

<alyver> I'm happy to participate in the network token discussion.

IJ: Roy are you still lead on the network side?

Roy: yes

<oyiptong> +1

IJ: Olivier and Manash work out who takes lead for gateway

Manash: I think we should organize a demo of how network tokens work

IJ: Any update on updated flow diagram?

Manash: I will check

next meeting

ClintonA: As you pointed out, I am hear with Amex affiliations but also participate in EMV in tokenization, remote commerce
... happy to be part of conversations

Next meeting: 6 June

<mweksler> +1

<oyiptong> +1

scribe: and in the meantime we will work to advance the gateway story