<Ian> NickTR: I don't have a report today but will walk through some notes
<Ian> ..I will take for a few minutes to try to talk about SRC, introduce some core concepts, and draw some headline conclusions
<Ian> ...so I request to get through the main narrative before discussion
<Ian> ...I have now reviewed the entire v0.9 specification
<Ian> ...my comments today are specifically about the relationship to the w3c ecosystem
<Ian> ..it's worth noting that EMVCo specifications need to be turned into implementation specifications by its various members
<Ian> ....6 card networks will now go off and create (compliant) implementations
<Ian> ...that's one of the reasons that this specification is hard to read
<Ian> ...it's deliberately unspecific on who plays which roles; it tries to leave as many doors open as possible
<Ian> ...this specification is very large and not yet finished
<Ian> ...the SRC task force has worked hard to get this out for public review, it's fantastic to get the opportunity to comment on it while still in motion.
<Ian> ...starting with the good news - to my mind, payment request and payment handler cannot only co-exist with SRC, but for the most part there's a really good technical fit
<Ian> ...however it's also worth noting that SRC describes an entire ecosystem (involving 3 different domains) and also ancillary processes around that (e.g., enrollment)
<Ian> ...it extends beyond checkout, whereas checkout is the focus of the WPWG.
<Ian> ...thus, there is an overlap and I'm confident they can work together, but that effort and ours are trying to do different things.
<Ian> Bryan Byrne intro video
<Ian> nicktr: The spec is clear that you can use EMVCo tokenization (but aren't required to; can use other things as well)
<Ian> ...the spec talks about payload
<Ian> ...in SRC the flow is:
<Ian> * Card holder selects a representation of a digital card. Verification steps are wrapped around that (recognition and assurance)
<Ian> * Then a payload is returned to the merchant and flows through the traditional rails
<Ian> ...there are also wider registration processes described for how people get onto the rails
<Ian> ...the complexity derives from the variety of flows and who can play which roles
<Ian> ..there are two worthy of note today:
<Ian> * Digital Card Facilitator (DCF)
<Ian> * SRC Initiator (SRC I)
<Ian> ..the latter is particularly important to PR API and PH API
<Ian> ...there is a third entity -- digital shopping application (DSA) -- in our world that is primarily a (merchant) Web site
<Ian> ...could also be a PSP hosted page
<Ian> ...see the helpful diagram (3.1)
<Ian> ...(note on reading this spec that SHALL = MUST)
<Ian> ...when an SRC trigger is fired (e.g., button, gesture, voice)
<Ian> ..a customer profile is built and the major consequence of that process is that a candidate list of available cards is built
<Ian> ...this process is analogous to canMakePayment()...there is a query of various systems to determine what's available, with assurance/verification.
<Ian> ...it's constructive to think about that as analogous to the first phase of constructing the PR API sheet.
<Ian> ...the checkout event allows things like addresses and other metadata to be passed around
<Ian> ...then there is a payload request, where you go off to an SRC provider to get this data to actually make the transaction occur (but that is not PAN data)
<Ian> ...then there is a fourth step (which turns out to be optional)...a confirmation message at the end that signals back to the SRC participants about the status.
<Ian> ...that happens after card authorization, which concerned me because in the PR API ecosystem, our flows finish prior to authorization.
<Ian> ...I was worried that we could not get the confirmation message through our flow, but it's optional. But it may need an extension point
<Ian> NickTR: Who can play the role of SRC initiator? or DCF?
<Ian> ..the boundaries between the two roles do not exactly align with the mediator and payment handler roles in our ecosystem, but there is a good deal of crossover.
<Ian> ...in particular, it seems to me that it's the role of the payment handler that's critically important in all of this
<Ian> ...SRC initiator manages messaging flows but also plays the crucial role of registration of sites and DSA's.
<Ian> ...we are familiar with that in the context of Apple Pay or Google Pay
<Ian> ...there's a registration step for Web sites and merchants
<Ian> ...I think for our ecosystem, it's important that parties can play the role of payment handler
<Ian> ...the SRC spec does talk about who might play the role of SRC initiator, and I've thought more along with Danny Russell and Matt Saxon about who might play that role
<Ian> ...we think that role might typically be played by a merchant service provider.
<Ian> ...I also anticipate each major network will implement SRC...and other parties might have payment handlers as well
<Ian> ..the other really good news, because there's an additional component around registration and who can be an SRC initiator; that dovetails nicely with our payment method manifest work
<Ian> ...so I think there is a good fit
<Ian> ...interesting question whether we end up with a single SRC payment method, or one URL per SRC implementation
<Ian> ....I could imagine each SRC programme wanting its own manifest
<Ian> ...I've not spoken about commerce aspects, but if merchants and PSPs need to register, that will require time and effort
<Ian> ...there's an interesting question about where the registry of SRC systems will live
<Ian> ...I'm not clear how an implementer would know where to find all the SRC systems
<Ian> ....if we want to carry confirmation messages we would need perhaps an extension point
<Ian> ...and there is likely to be a certification regime; that's not yet articulated in the spec and I'm not aware of any public implementations
<Ian> ...so it's not clear yet to me how to build against this.
<Ian> ...but there's nothing that I see that would prevent SRC from existing with the PR/PH API ecosystem, and payment handlers are clearly important to this.
<Ian> AdrianHB: Nick, do I understand that the likely SRC initiator would be a payment handler?
<Ian> Nick: Yes, that would be a good way of implementing SRC in this ecosystem
<Ian> ...even if not an exact fit
<Ian> ..there's also an idea of "common" software and "system" software...common is an aggregation of capabilities
<Ian> ...you could see the browser and payment handler could be good places for that to occur
<Ian> ...there's also a possibility that there might be N > 1 payment initiators in a transaction.
<Ian> Laura: My understanding is that the initial plan is that the SRC-I would be (in the long term) a party one could integrate into 1-time
<Ian> ...until there are more broad SRC-I's, then there might be per network SRC-I until there is a capability for more parties to fulfill this role.
<Ian> ...I believe the plan is for existing products to transfer to SRC next year
<Ian> ...so there could be multiple SRC-I's
<Ian> ...how will this impact the merchant?
<Ian> nicktr: Great question. I speculate that the first SRC-I's out of the box will be evolutions of existing scheme wallets
<Ian> ...those will exist when SRC first comes to market, and over time I expect more parties to play that role
<Ian> ...so this is where the addition role of the mediator comes in
<Ian> ...the mediator can provide a list of handlers and also display different credentials held in those handlers
<Ian> NickTR: That aggregation of different experiences could happen in the browser-as-mediator
<Ian> ...or in payment handlers (which might be the browser as well)
<Ian> lte: What would the user experience look like?
<Ian> ...my understanding is that the user experience design is being shared
<Ian> Laura: I am concerned if the user experience is being designed without the expertise of the UX designers in browser vendors
<Ian> ..are you saying you feel comfortable that the UX can be entirely managed by the browser or web site?
<Ian> NickTR: I'm confident that that *can* be done
<Ian> ...I think that our framework of specs allows for that
<Ian> ...interestingly, the EMVCo spec has an appendix that talks about UX and UI, but that info is not part of functional requirements
<Ian> Laura: I realize there is an expectation of more UI Guidance around SRC
<Ian> NickTR: Suppose that there are multiple SRC-enabled payment handlers
<Ian> ..those can still be represented in the payment sheet
<Ian> ..the best example today is the chrome implementation where you can have both a pay-with-GooglePay, and cards-in-browser ... and if you have other handlers, they are all available through the sheet
<Ian> ...and within a payment handler there may be another user experience
<Ian> ..you can't have an open ecosystem and constrain how many people can appear in the initial choice.
<Ian> ..I think market forces will sort this out.
<Ian> Laura: I will remain optimistic that the UX and choice will remain open
<nicktr> scribenick: nicktr
ian: in a world where there are multiple SRC programmes, each identified with its own URL, would there be a common data model? Or do we think the merchant will just say "I do SRC"?
<scribe> scribenick: ian
tony: One concern we have with
SRC is that anybody can define their own specification for SRC
I...the merchant has to code potentially to multiple
SRC-Is...so I think the payment handler can help from the
merchant standpoint
... regarding control of UX, that's another area of concern for
us
... there are some issues about ordering of responses
... from multiple SRC systems
Giulio: Thanks also to Nick for
distilling the spec
... one observation...it seems to me that before the spec was
made available, and based on statements from the networks,
there would be an "SRC Button"
... designed to replace multiple network-specific
buttons.
... is that talked about in the spec?
NickTR: In the earlier drafts of
SRC, that was more strongly stated (SRC trigger)
... one way to implement that is with a (branded) button, but
there are other ways to trigger.
... I think the requirement that there be one button per SRC
system has either been softened or removed
... I think you can make an argument that it would be possible
to build many different user journeys, where you could point to
some kind of interaction and say "That's the SRC
trigger."
... I think it's possible that it could also be a button
somewhere else..the challenge is that in the current
specification...the trigger is what lets you build the
candidate list
... that trigger in our ecosystem would also invoke payment
request, but it might be possible daisy chain those
... in the EMVCo spec there's (more) wiggle room now
... I can't speak to what the networks actually plan to do
danyao: Regarding the UI
stuff...
... in the previous meeting Rouslan mentioned that we are still
open to discussion about the sheet and selection of
instruments
... we'd like to give users options to select as many options
as possible, but discovery is also important, as well as
performance
... we may also want to give merchants the opportunity to
register payment handler preferences
... we hope to continue to work on UX and are seeking
feedback
... we want more people to implement payment handlers and give
feedback
<Zakim> AdrianHB, you wanted to ask about SRC initiator and merchant relationship
AdrianHB: Something that's still confusing to me: on the one hand we are talking about SRCI-as-PaymentHandler
<lte_> love the idea of merchant preference for payment handles
<lte_> handlers
AdrianHB: We are talking a lot
about the relationship between SRC-I's and merchants, and
merchants would install support for an SRC-I
... but our model is that the merchant would support for a
payment method
... and any initiator that supports that payment method can be
used, and it's the user that chooses
(Ian: This is my point from previously....merchant could list a set of PMIs, one per programme)
NickTR: At the moment there is a
requirement on the SRC-I to register the digital shopping
application (merchant site or PSP)
... that will use that SRC-I
... and the direct comparison would be the way that merchants
register with Apple Pay
... that doesn't mean that you can't have payment handlers that
aren't registered
AdrianHB: It seems me that that
probably the best example we have of an ecosystem that could be
replicated with SRC is Google Pay
... the way that Google Pay is implemented in Chrome is a
Web-based payment handler
... there is a URL PMI, there is a merchant registration
requirement, there is a payment handler
... and my understanding is that we could have an equivalent
for SRC or for each SRC I
NickTR: Agree, but equally a
merchant could have a handler or a PSP or a group of merchants
or an acquirer
... what can't exist under SRC is a completely unregistered
relationship between SRC-I and the merchant
IJ: The advantage is that even if registration is required behind the scene, there's a finite set of PMIs and (ideally) a common data model
NickTR: It would be great if EMVCo had a single URI PMI with a manifest and a single common data model, but my expectation is that it's not a model that exists today and unlikely to go in that direction
AdrianHB: There are layers there
that make this flexible, and it's quite possible for EMVCo to
publish a payment method spec (for the data model)
... and each network publishes its own URL PMI
Laura: In the scenario where the
merchant has a trigger available, would the merchant still have
the choice to determine who is the initiator behind the
URL?
... or is that choice decided by SRC-I-Visa or SRC-I-MC?
AdrianHB: In terms of what the
API supports today, that would depend on the data model of the
payment method.
... e.g, if you say "I accept SRC via network X"
... it's possible in terms of the design to add constraints
Laura: General comment - a couple
of promises that were made around SRC were (1) ease of merchant
integration and (2) consistent UX
... I am not hearing that; I'm hearing mostly about
security
... from a merchant standpoint, we just want choice about
integration our experiences into our web presence.
NickTR: I will prepare my
comments for the feedback form
... I am happy to orchestrate other comments people want to
send my way
... as co_Chair I will talk about interop among the specs
... others can send comments and also respond directly
IJ: I propose that NickTR
responds but not "on behalf of the Web Payments WG." I don't think
that formal endorsement will add value to the review (but
I may be wrong). People can send
Nick comments who can include them, or they can also respond
directly to EMVCO.
... I like Nick in his communication "I am the co-Chair and it was my job to
collect comments and here are mine and others"
... Clinton, would it add weight to make it a FORMAL
response?
Clinton: Any feedback we get will
be beneficial, not sure there would be incremental weight to
formality
... but consolidation is helpful. Note: I
am participating in today's call as American Express. Not EMVCo.
<AdrianHB> I am in favour of us reviewing the text that the WG prepares BEFORE we decide in what capacity we pass it on
+1 to review of Nick's text before sending to EMVCO
NickTR: If it's written down, there's a document that comes back (response to the comments)
<scribe> ACTION: NickTR to write down his SRC review for WPWG review, due 2018-11-23
<trackbot> Created ACTION-109 - Write down his src review for wpwg review, due 2018-11-23 [on Nick Telford-Reed - due 2018-11-22].
<AdrianHB> Based on today's discussion it seems SRC will rely heavily on PH API so we need to find a way to get more browsers to implement
IJ: There is consensus but I want to pursue the question of specifying handling of the deprecated feature and need more time.
IJ: I plan to schedule a monthly call; stay tuned
Postponed to next meeting
29 Nov