Resources referenced during this call:
IJ: Any card networks want to raise issues or indicate support for the proposal?
Clinton: We (American Express) are still evaluating
the proposal
... I expect more concrete feedback in the near future.
... overall we see that the flows are at least consistent with
our expectations
... we should have concrete feedback by next call
Fawad: I chatted with Ian yesterday. We are also still reviewing internally and probably will have concrete feedback in 2 weeks as well
IJ: Would any other materials be useful for the review?
Fawad: For Discover we have what we need.
Clinton: We also think the materials are sufficient
IJ: To ensure that EMVCo is tracking this work I've chatted with Bastien Latge. My takeaway from those discussions is that when we would like their input, we will send them materials (e.g., a FPWD of a payment method). Any other suggestions for ensuring we are getting EMVCo feedback at the right time?
Clinton: We'll not want to
duplicate work Tomasz has done. I would want to have to repeat
the work in an EMVCo environment.
... so I think ironing out consensus here first and making
clear that this is a direction where there is consensus, will
make it easier at emvco
... Try to bring stable proposal to EMVCo
IJ: The proposal here involves an origin that is co-inhabited by the different card networks. Who might host the common payment handler and that origin?
Tomasz: We don't have a concrete proposal for that yet.
IJ: Is this a question where we should get early EMVCo input?
Fawad: I think of it more as a card brand discussion.
Tomasz: I agree
IJ: Please think internally about this question as you (card networks) continue to evaluate this proposal.
JonathanG: I think if we can agree
on the architecture and start a POC, that would be great
... we can postpone the origin question a bit
Clinton: I think we could raise
this more within the EMVCo SRC WG
... as a foundation to the proposal, it is a question to be
answered
<Zakim> rouslan, you wanted to ask for a friend how would one join the SRC ecosystem as a payment app (SRCi?)
Rouslan: How does one join the SRC ecosystem?
Clinton: There are a variety of
SRC-Is that are establishing themselves. Issuers have an
entryway through SRC system. Merchants through SRC-Is
... is the question how, as an SRC-I how to integrate?
... I think the SRC-I needs to establish itself on one side
with merchants, and on the other with SRC systems
<AdrianHB> What is an examples of an SRC-I today? Are existing companies fulfilling that role?
<Zakim> rouslan, you wanted to ask where the merchants redeem the SRC tokens
rouslan: Once the merchant receives the payment response payload (including a token), where do they redeem the token?
clinton: I think
you mean "where do they submit it for authorization."
... once the SRC workflow is complete, a merchant will have
either a PAN or a token. The assumption is that that is
interoperable with any of their existing authorization
channels.
... so a merchant should be able to use their existing value
chain for authorization
Rouslan: When a merchant uses google pay
today the merchant needs to specify a PSP and some key info
... in the response the merchant needs to refer to the same PSP
Clinton: I think that the token
that one receives from SRC, if we are assuming they are payment
tokens, then they are interoperable within those various
channels.
... if they receive a reference to a token, then there may be
incremental dereferencing processes they need to go
through
... if we look at something like a security token, they would
have to dereference it from the token provider
IJ: What about domain controls? Will those add complexity to this architecture because they assume tighter connections between merchants and SRC-Is?
Clinton: The way I would answer
that is that the domain restrictions placed on a payment token
are mostly independent of the SRC system and more relates to
the tokenization system.
... I think you are referring to something that may be
implementation-specific to a particular tokenization
environment
... I don't think SRC itself would limit the interop
<Zakim> rouslan, you wanted to say thanks
rouslan: My goal is to enable very interoperable payment handlers. I want to figure out how far we are from that.
jv: There is something about understanding how this works. It affects the security model ... where can tokens be reused. It's important to understand: is it reusable by multiple merchants? Single use token?
Clinton: I think what I'm hearing
is: from a payment handler perspective, there's a lot of
decoupling ... whatever the payment instrument is, wherever it
comes from there are a lot of layers of indirection. Because
those layers do not provide restrictions on instruments, the
merchant does not know what it can do with the
information.
... they don't know whether constrained by their own merchant
ID, or by dynamic data.
... the underlying subtext is that metadata about the token
might be valuable.
... in the response data
... right now in SRC and tokenization that metadata does not
exist
... it's expected to be communicated as part of direct
implementation
IJ: We have had some preliminary discussions about this type of metadata; see our wiki about SRC data. Is there a standardization opportunity for this metadata?
Clinton: If a merchant has an
existing relationship in a token environment, then it's likely
that there are domain controls associated with that
relationship
... but here we are talking about a scenario where the merchant
(as a user of a token) does not have the information that the
token requestor has
... it's my expectation that communication between token
requestor and token user is not currently in scope in the
(tokenization) spec (from EMVCO)
... I think at a minimum creating a communication channel is a
start
... then creating data model that is consistent across systems
would be the next step
... but to start having a communication channel for
communicating intended use will be helpful
Tomasz: We talked about this some
time ago
... my view is: EMVCo is working on SRC where the data elements
are already defined
... we should really focus in this WG on the communication
channel and reuse the SRC Primitives
... Regarding SRC-I custom data, I think we should be looking
into this in the payment method spec
<clintonallen> Two categories of token domain restriction controls may exist in an SRC ecosystem, Shared and "normal" shared will be defined by the existing Dynamic Data enums in SRC while "noermal" will be defined "identified" by the TDRC associated with a TRID.
clinton: TDRC = token domain
restriction controls
... TRID: Token requestor ID
... A token requestor gets an ID when registering with a token
service provider
... SRC participants may have existing relationships with Token
Service Providers
IJ: We should have SRC-Is in the discussion to make sure they are on board with this
Q. Who is the token requestor in this model/
Clinton: The SRC system (most likely)
Tomasz: +1
IJ: Does TSP put in domain controls as a function of the token requestor?
Clinton: Yes
Tomasz: +1
IJ: Does it matter which SRC-I is used to get a token?
Tomasz: Dynamic data comes from SRC-I but the token is the same
<clintonallen> +1
Clinton: the dynamic data may be originated from one source, but is communicated or facilitated by the SRC-I
IJ: I want to make sure tokenization will work in this proposed architecture
Tomasz: The trust relationship is
pretty much the same between the merchant-side integration
and PR API.
... all we have here is browser-as-mediator between merchant
and SRC-I
Tomasz: so in the merchant side
solutions SRC-I is triggered directly by merchant, in PR API
world, is triggered indirectly through browser
... merchant has to identify itself in both cases.
... and consumer id is another topics
clinton: I wanted to confirm....are you saying that where the browser is an intermediary, that we need to figure out how to identify the merchant?
tomasz: The same controls are in
place whether this is PR API or outside of PR API
... the trust model does not change in my opinion.
... there are different ways for merchants to invoke
SRC-Is...that's not specified anywhere
<scribe> ACTION: Tomasz to think about (and maybe write up) some text on the trust model topic
29 April