Tokenization Task Force

26 Jun 2018



stpeter, Ian, Rick, Simon, Ken, Manoj, Krystian


<scribe> Scribe: Ian


Updated Tokenized Card Payment Specification.

Tokenization Spec

Tokenization Spec

Previous meeting minutes


Issue 44


Rick: When you get basic card details and you store for card-on-file, the dynamic data is usually the CVV
... so each time a transaction is initiated, the cardholder will have that information necessary to support the transaction, but with a token the user won't.
... so my question is whether "card-on-file" is still an appropriate use case if dynamic data can't be easily retrieved in the future.
... for recurring and one-time-use, what you receive through PR API is sufficient (and you might not need dynamic data for subscription)
... but for spontaneous card-on-file transactions, the token might be stored, but no dynamic data to accompany it
... so should we remove card-on-file use case, or look at some method for getting dynamic credentials (through PR API or some other means).

IJ: What relationship needs to exist to get the dynamic data in the first place?

Rick: usually the token requestor would have access to a TSP API that would provide dynamic data for a specific transaction
... e.g., a cryptogram in a 3DS value, or an assurance value

IJ: What would not work about a callback URL from the token service provider?

Simon: If the merchant is the token requestor they already know how to do this
... they can ask for it through existing channels
... if the merchant is not the token requestor, then they need to have an interface to the token requestor.

Manoj: +1
... I like the approach of providing a reference to the merchant that can be used to get a token+cryptogram from the network or TSP


IJ: What if the response data were ONLY an endpoint, and the token never went through the API? That would unify all the use cases.

stpeter: This seems out of scope for PR API
... it's up to merchant to figure out how to re-auth

IJ: My sense is we either (1) drop card-on-file or (2) give back info that enables merchant to get subsequent dynamic data

stpeter: Does data come back from the user or some other party?

(IJ understands it is not from the user)

Rick: The value is provided is usually linked to the transaction (e.g., through a hash or algo)
... so decline may happen if token/crypto re-submitted
... so today there is a "Transact" API provided by scheme or issuer that the token requestor calls

stpeter: Understand that we do not reach back to the user

Rick: If the merchant has a way to connect to the backend (through web or another api) with token ref API and they get ack a hash, that increases chances of approval

IJ: Who is calling the Transact APIs?

Rick: It is the token requestor.

IJ: Who is getting the dynamic data the second time? Merchant? Stripes of the world?

Simon: EMVCo does not define who has to be the token requestor
... TSP might recognize Stripe or the merchant directly

stpeter: I go back to my point - we are designing here a payment method for PR API, to my mind, as long as we have a way let the user and the merchant agree on what kind of token is being created, then it's out of scope to specify how it all happens on the backend

IJ: I am hearing we could clarify that (1) relationships exists or (2) pre-existing relationships are not assumed to exist, and therefore we need to provide additional information (e.g., a callback URL)
... In a world of pre-existing relationships, the TSP could also just return a string and the backend processes could get all the data

Manoj: Shouldn't the merchant be conveying through PR API who is the relationship is with the TSP?

IJ: PR API + tokenization assumes there was no need for a pre-existing merchant-issuer relationship BEFORE THE FIRST TRANSACTION.
... however, I am understanding that for SUBSEQUENT activity with the token, there needs to be information available to token user about which TSP generated it.

Simon: Yes
... merchant can't randomly go through different token requestors to get new dynamic data;
... they need to go back to the original token requestor (as the requestor and token are tied together)

IJ: Since you have trid in response data, is that sufficient?

Simon: That may not be sufficient but it's a big clue
... you have a combo of token requestor AND which TSP is involved

stpeter: It's reasonable that this is how things work.

simon: TSP identity is part of the trid

IJ: So my question is "does trid suffice"?

Simon: You need to know who the party is and have a relationship with them already

stpeter: More likely is that merchant has API into Stripe and they deal with it.

rick: Agreed; question is whether these relationships exist


1) We make explicit that relationships among relevant parties are assumed to exist for subsequent card-on-file transactions

Manoj: How is the trid derived?

2) Value of PR API + tokenization is the initial capture of the data


- card on file use case assumes relationships exist

- if we assume those relationships, can we simplify the data model further?

IJ: Anyone want to review the data model to see whether we can simplify under the assumption that the relationships exist?

Rick: I can have a look at it

<scribe> ACTION: Rick to work with Ken to evaluate the data model to see if it can be simplified in light of assumed existing relationships among token requestors and TSPs.

<trackbot> Created ACTION-99 - Work with ken to evaluate the data model to see if it can be simplified in light of assumed existing relationships among token requestors and tsps. [on Rick Waller - due 2018-07-03].

next meeting


<scribe> ACTION: Ian to schedule 17 July call and send around 1-time call details.

<trackbot> 'Ian' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., IFSF-EFT-WG-Lead, ijacobs).

Summary of Action Items

[NEW] ACTION: Ian to schedule 17 July call and send around 1-time call details.
[NEW] ACTION: Rick to work with Ken to evaluate the data model to see if it can be simplified in light of assumed existing relationships among token requestors and TSPs.

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2018/06/26 16:44:02 $