<scribe> Scribe: Ian
https://github.com/w3c/webpayments-methods-tokenization/issues
https://github.com/w3c/webpayments-methods-tokenization/issues/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
https://w3c.github.io/webpayments-methods-tokenization/#tokenizedcardresponse-dictionary
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
IAN PROPOSAL:
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
Summary:
- 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].
17 JULY
<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).