<scribe> Scribe: Ian
IJ: Any take on the discussion especially on 20 March? Key findings?
stpeter: Helpful discussion; encouraged by progress
Tokenized Card Payment specification
[IJ walks through changes]
keyur: I sent you a draft version of the encryption scheme.
Keyur: Regarding
"TokenUsageType": there can be recurring payment with a
one-time token
... and can also be performed with card-on-file
... for card-on-file credentials, it shows up as a new
transaction on the user's bill
... so one-time token can be used for recurring payments so
long as user has agreed
Simon: That feels a bit
conflicting from an EMVCo perspective. Single-use token is for
a single use
... this might be a case of terminology.
... if you have card-on-file and it's a split shipment, then
you would have a merchant-initiated transaction
... the card-on-file token can be reused in that context
Keyur: I think I also shared the types of payments that can be used
so we have:
<scribe> * NEW
* RECURRING
* PARTIAL SHIPPING
mweksler: I wanted to speak to
the card-on-file use case brought up in Singapore.
... Merchant-initiated payment matches the card-on-file use
case
... in subsequent interactions, customer indicates desire to
create new transaction but they don't add their card again.
Keyur: I think the fourth type can also be called CARD-ON-FILE
mweksler: we could align with emvco terminology and call it merchant-initiated
IJ: Is there a diff between initial expectation and subsequent usage?
<Simon> Chapter 6 I believe
mweksler: For recurring, you know
in advance about recurrence
... For something that happens multiple times but is NEW (you
don't know how much or when), the user needs to complete
transaction each time.
IJ: Is the distinction "recurring" and "other" where "other" can be used for 1-time and subsequent transactions? (card-on-file)
mweksler: the PR API needs to indicate to the TSP what kind of token is requested; even for new subsequent transactions
keyur: EMVCo certification is
more from a TSP conformance perspective
... I think these two are separate things and we may create
confusion
... I would rather look at it from a merchant perspective; what
kind of payment they think it is
... the spec should address the merchant needs
mweksler: Quick note - I am
worried if we say "other' we will set ourselves up where
default behavior won't be adequate for card-on-file use
case
... I am guessing you do need to so something explicit for for
card-on-file use case
stpeter: I'm interested in the
user perspective. :) What am I authorizing this interaction to
accomplish?
... if there are several shipments, for example, from the user
perspective do we need to highlight a distinction?
... I agree with mweksler that "other" doesn't feel descriptive
enough to me.
... specifying those as well between user and merchant seems to
be our remit here
keyur: stpeter brought up a good
point about how the usageType translates into user
experience
... at least for MC, recurring/partial shipment/one-time use
are similar in terms of both payload and usage. But
card-on-file is different.
... the merchant or acquirer has to get a cryptogram (via a
backend API) and use it for a new transaction
IJ: Do you have to have a different token to do that backend call?
Keyur: Yes.
SachinAhuja: I agree with Keyur
and previous comments that the API should be merchant/user
focused
... to stpeter's point, the issue that you are raising is more
of a PR API issue itself rather than a tokenization
issue.
... when, via PR API a credential is passed on behest of the
user, the user should know what will be done
... maybe that should be done at the PR API level
[IJ Thinks that's a reasonable idea, but not convinced it should be elevated yet]
stpeter: I have a clarifying question about card-on-file and merchant initiated....are those considered the same thing?
Rick: cardholder v. merchant
initiated....who initiates at a point of time
... anything other than user-initiated (even in case of
card-on-file)
... here's my summary:
... of merchant initiated:
- Incremental charges
- Resubmission
(after decline)
scribe: incidental charges
- installments
scribe: you have service up front and pay retrospectively
- recurring
scribe: so there are 8 or 9 merchant-initiated types of transactions
mweksler: I agree with Rick's use cases and would add the obvious one - the user says "I want to buy this" using my existing card-on-file
Rick: that's a cardholder-initiated transaction
mweksler: Some merchants might not use PR API for that use case
rick: I think it's a fair point
from mweksler; there is probably a wider industry effort to be
made regarding merchant behavior
... the need to remove static data from databases becomes
greater...as an industry we need to look at how to use dynamic
data
mweksler: Three points
- tokenized card is a network token that is NOT PCI-scoped
scribe: that's a bold statement
I've heard and want to be corrected if that's wrong
... this means it can be stored in a database and poses no
security risk
... if we view network tokens in that light they can be easily
stored in card-on-file
... and if you need to request crypto, that adds a layer of
security
- other point - we need to be careful about our goal in writing this spec
scribe: we want to balance direction of industry with what is actually done
stpeter: mweksler raises a good point. From my limited browser vantage point, there's a distinction we might want to draw:
- single click checkout
scribe: that could still be cardholder initiated
Rick: On the PCI front - from a
simple overview perspective, PCI still classifies tokens as
data that needs to be encrypted
... it's still a PAN at the end of the day
... but it's restricted in domain use (certain merchant,
certain interface)...so limits risk
<keyur> https://www.pcisecuritystandards.org/documents/Tokenization_Guidelines_Info_Supplement.pdf
mweksler: I agree with stpeter
that we want to enable 1-click through PR API
... in a world where merchants get tokens through PR API, it
makes sense to get a token in 1-click fashion
... and without creating additional UI under the right
conditions
... we want to allow that but it's not the current world we
live in
... if we don't support current usage of card on files,
merchants won't use card-on-file
... If tokens are PCI-scoped, then merchants won't use
them
... I've heard conflicting accounts on this front
https://www.pcisecuritystandards.org/faqs
<Simon> https://www.pcisecuritystandards.org/documents/Tokenization_Guidelines_Info_Supplement.pdf
How does PCI DSS apply to EMVCo Payment Tokens?
<Simon> section 3.1.2
one-time
card-on-file
recurring
Keyur: "one-time" doesn't really capture it
<stpeter> mweksler: we might want to investigate use of Payment Handler or a URL-based payment method for single-click checkout
<mweksler> ah got it
IJ: I am hearing from Keyur "card-on-file" and "other"
rick: Some reasons people might
request token (and get domain controls on them) - one-time,
recurring, card-on-file....
... as part of the w3c API in the PR API is give the merchant
the option to tell the schemes what they want
... If the two use cases are guest and card-on-file, then
"one-time" and "card-on-file" ... you may also want to put a
time factor on a token....how do you get dynamic data (do you
make a separate call to the schemes?...do you have to set up
your own API to get dynamic data?
sachin: What are next steps on
this?
... in Singapore there was some interest in prototyping.
IJ: +1
<Ken> +1
Sachin: Mastercard interested but we need some additional participation from merchants, browser
IJ: I think Adam Solove and Gildas have volunteered some time I believe
<marconi> +1
stpeter: I need to talk to our prog. manager re: resources
<mweksler> +1 - we'd like to participate in prototyping
marconi: Cap One would like to help in this project
Ken: Amex can bring some resources to the project
Sachin: I think Mozilla participation important here
<scribe> ACTION: Ian to figure out next steps on TokenUsageType values
mweksler: Quick note regarding
the question about dynamic data...
... in my mind today merchant would get dynamic data through
PSP at least today
... that relationship needs to exist anyway
... maybe in the future get dynamic data through PR API
stpeter: On terminology I think
we are measuring concepts in 2 dimensions (merchant,
user)
... I'm not sure where we are going to land but want us to
think about both perspectives
15 May
<mweksler> +1 on 15 may