Tokenization Task Force

==> https://lists.w3.org/Archives/Public/public-payments-wg/2017Jul/0050.html Agenda

Gateway params updates

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

olivier: No changes; need to sync up with Keyur

<oyiptong> https://github.com/w3c/webpayments-methods-tokenization/issues/10

Issue 10

Reminder here is gateway params wiki => https://github.com/w3c/webpayments-methods-tokenization/wiki/gateway_params

<oyiptong> https://github.com/w3c/webpayments-methods-tokenization/wiki/gateway_params#token-providers-and-iin-routing

oyiptong: I want to speak to this issue with a diagram

<oyiptong> https://user-images.githubusercontent.com/9365/27572522-63cf432a-5ac1-11e7-939a-cfb155c52411.png

oyiptong: the diagram illustrates a flow
... typically we have several gateways, each of which connects to an acquirer
... we may still want to do routing do a different acquirer even if we have one gateway
... e.g., we might want to use an acquirer familiar with portuguese cards to increase acceptance rate

<oyiptong> https://github.com/w3c/webpayments-methods-tokenization/wiki/gateway_params#payment-request-response

oyiptong: so that's the rationale for including the IIN in the payment response

IJ: Which party is doing the routing?

oyiptong: The merchant, based on first 6 digits of the credit card

Simon: FYI, that standard is in flux...it will go from 6 to 8
... ISO 7812
... there are some intentions to adopt the 8-digit IIN

SteveSommers: I have a quick question about 8-digit IIN. Is that just for longer cards?
... that won't leave lots of numbers to tokenize

SimonDix: There are also discussion about longer PANs
... but some issues around that as well

[More discussion about PAN length..]

clintonra: I am looking at the diagram. If I understand correctly, the response from the payment handler includes the IIN. The expectation is that this will include some information that merchant can be used for routing.
... The payment handler gets a token back from the token provider. either the handler retains the IIN portion or something that can be used for oruting

oyiptong: Right now we use IIN for routing, but if something else comes up that we can use for routing, we would use that.
... many merchants build models to improve acceptance through routing

clintonra: I understand the use case. Thank you.

IJ: Should we talk about "routingInformation" here and allow for some flexibility?

oyiptong: I can see that.

IJ: Is there something else in practice? Would you need type information in addition?

MattS: I think adding routing information at this phase is premature optimization.
... I'd rather stick with IIN for now.

clintonra: I understand the need for routing information. But in the use cases diagram, the response back from the token provider...what I'm trying to figure out is that ...when you receive a token and you receive which token you are going to route, aren't you already inherently selecting the acquirer in the selection
... I come back to the scope statement ... limiting token-to-processor as 1-1 relationship.
... the routing is linked to whoever provided the token
... in what situation would the routing be beneficial?

oyiptong: One gateway gives us access to multiple acquirers. Most of our gateways allow us to choose which acquiring bank we want to use. So it's 1:1 with the gateway, but not the acquirer.

clintonra: And the assumption is that the merchant, not the gateway, needs to make the decision?

oyiptong: Yes. The gateway provides APIs but we (the merchant) have to choose the acquirer.

<oyiptong> +1

<MattS> +1

PROPOSED: Keep IIN in the spec

<MattS> +1

<cweiss> +1

<clintonra> +1

SO RESOLVED

Issue 11

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

oyiptong: We discussed. I think it should not be in the spec for now.

<oyiptong> +1

<shift4sms> Question - might this be a gateway specific solution? As a gateway, we choose the routing for the merchant based on setup/negotiation with the merchant. From what I have seen of my competitors, I'm not aware of acquirer specific APIs through the gateway.

IJ: Please point to discussion in GitHub and close for now.

<MattS> +1..... for now

MattS: Our gateway allows merchant to leave information out and Worldpay does routing, OR we allow merchant to provide routing rules
... and we are aware of customers who have multiple gateways
... so I agree this is a complex relationship.

Issue 12

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

Should the response data include an "expires" field?

SteveSommers: By expires are you referring to the token?

Ian: Yes.

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

<shift4sms> If it's optional, I would say yes, add it.

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

MattS: If gateway params is where we do updates, I'm fine with that. But the structure of the article is discursive
... I've raised some issues
... Another observation ... one of the reasons I raised so many issues is that wikis don't lend themselves to PRs.
... I suggest we move it into respec

<oyiptong> +1

Ian: My mild pref early in the life of a document is very easy editing

oyiptong: I think I feel it might be too early to make it look like a spec...but maybe I'm wrong
... but if people want to move to respect (with light review) I am ok

MattS: I would say that the person who contributes the most choose choose the tooling.

oyiptong: I would punt a bit more until we have consensus with master card folks (at least)
... +1 to moving to respec once more stable

<oyiptong> +q

oyiptong: I want to give the merchant perspective on the expires field: I think it would be "nice" but sometimes it's hard to predict.
... as far as we go, I think that we try a payment and if doesn't work we do something else. We might get an error response from the gateway and deal with it.
... I think the expires field is "nice to have" but I'm not sure if it's the primary source of information for invalidation.

IJ: Please add a sentence to the GitHub issues list
... on that topic

Issue 20

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

MattS: If the merchant has saved the token, then it seems the merchant would want "expires".
... for oneTime use, expires is less useful since you just got the token

oyiptong: My intention was this - token would not be included in subsequent transactions.

mattS: Expiry can still be useful in oneTimeUse - you could use it later
... you could authorize the transaction at one point and then capture the payment later using the same token.

oyiptong: We do use that pattern.
... the timeout for this probably differs based on the processor. I think for us it's "within 3 hours"

MattS: That's why I think optionally it should be in the data

oyiptong: +1. I agree with you

MattS: A multi-use token COULD be provided again and again to a merchant for multi-use
... if the merchant doesn't want to store it, you could argue that there are pros and cons from a security POV.
... I think "MAY not be returns" is more accurate than "will not be returns"

oyiptong: I implemented a feature for this. Right above subsequent card info there is a tokenprovider-merchant identifier
... this one is stored in the client by the payment handler

<oyiptong> tokenProviderMerchantIdentifier

(see this issue => https://github.com/w3c/webpayments-methods-tokenization/issues/18)

mattS: Ah, I read this as the "merchant's identifier, at the token provider" not "the token's identifier"

oyiptong: The idea is that we don't want to store the token on the client either
... the token could be obtained maliciously
... so the token itself is not persistent. It is only sent the first time to the merchant
... for subsequent use, the merchant gets an identifier

mattS: That wasn't apparent in the text. E.g., Apple Pay stores a token on the secure element of the phone, with an additional cryptogram
... each time you create a one-time token based on the stored token

oyiptong: Right, this tokenProviderMerchantIdentifier is derived from the token.

<oyiptong> +1

MattS: Please explain the usage of it in the document

(IJ: asks that oyiptong also look in the issues list and add explanatory notes)

IJ: How far did we get in answering 20?

MattS: I said "could be return multiple times" and oyiptong said "secure elements are sometimes used"....
... effectively all the tokens are "one time"
... I'm starting to get it!
... I need to go back and think about it

Issue 16

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

Where does tokenisation occur in the the flow - and do we care?

(IJ reads from the issue)

IJ: I think things like the diagram need to be updated; tokenization can happen outside of flow or token might be cached.

clintonra: There may be scenarios where the token that you retain independent of authorization would require additional information at time of authorization
... it might be worthwhile to have an indicator whether a token is usable "ON ITS OWN" or whether more information is required "AT TIME OF AUTHORIZATION"
... so there may be some scenarios where you can't simply use "what's stored" without more authorization
... Let me use network tokens as an example.
... suppose you receive a network token ... the token response might include information unique to the transaction...if the token is multi-use and it were decoupled from later authorization, the token might only be useful in conjunction with something else unique to each transaction (e.g., cryptogram)

oyiptong: in network token situation, if I am hearing, you may require some additional information for subsequent use
... I think this is a point where network tokens and gateway tokens diverge
... I think for gateway tokens we want for offline use...but it's not clear for me that this is the same use case for network tokens..if the user is online, the network token spec, I guess, could include information...

clintonra: Do we have anything documented around what "online use of token" means v "offline use of token"

oyiptong: My definition is "user is online at the time of transaction?"
... more specifically: "a party can get more information from the user, e.g., for authorization"

MattS: Might reach user through text (instead of HTTP, for example)

clintonra: I like MattS's framing - whoever is responsible for cardholder authorization is available for interaction

oyiptong: I think it might be useful to think about this as synchronous / asynchronous

MattS: What about real-time (matter of seconds) v. non-real-time (matter of hours)

oyiptong: that's correct
... regarding "additional information" mentioned by clinton, ideally for subsequent card usage, you want to minimize user interactions
... it's hard to request that the user do something (complete challenges) in a non-real-time way

clintonra: Great point. the idea that within this token request API there is a sense of "real-time transaction"...from a payment request perspective, is there something that's necessary to enable the merchant to say what they expect to do with the response (e.g., to use over a short period of time or an extended period of time)?

oyiptong: I think that it might be partly a failure on my part to articulate this...the intention for having this ID for subsequent card usage is precisely for something like a subscription.
... the merchant gets the token...for a single transaction there is an ID passed, but the ID is on the merchant side for subsequent use
... the merchant has the token...and the intention is to charge the user later; I can add prose.

<MattS> Can I suggest we articulate such prose as a set of scenarios

8 August

<MattS> in a separate wiki article

Next meeting

8 August