Clinton: We've reviewed the proposal. We have some questions about specifics, but are not overly concerned with anything in the proposal. It's good progress. We'd like to continue to push forward.
IJ:Would you prefer to discuss details here or via GitHub?
Clinton: GitHub
... I meant "built in support of the payment method"IJ: Who would host the
origin?
... Who will create the common payment handler?
Clinton: I think it could now be
a good time to get an answer to that question.
... I hear a tentative consensus, so good time to raise with
EMVCo
Jonathan: +1
<Fawad> +1
<benoit_> is there any desire to create a shared/cooperative/alliance that would code, review, host, and maintain this? or are we asking if there is a single entity willing to take this on?
IJ: What questions should be asked within EMVCo?
jalpesh: I think that question is
important (on hosting)
... +1 to discussion at EMVCo
Clinton: One interesting topic is how best to communicate the proposal within EMVCo. I can have a better time frame sense in a week or so
IJ: Maybe we can do a presentation (e.g., starting with MC work)
Jonathan: +1 we can work with you
IJ: Thank you ; we'll come back to this on next call
IJ: The upcoming https://github.com/w3c/webpayments/wiki/Code-A-Thon-2020 provides a good opportunity to do some work on an SRC proof of concept. Who would like to participate? Take the lead? Is code-a-thon useful?
Clinton: We think a POC would be valuable; unable to take the lead at this time
Gerhard: We are planning in
participating in the code-a-thon. We are reviewing options and
have a number of ideas
... we could be interested in an SRC project
... how could we bootstrap an SRC payment handler or put an
identity into it
IJ: Should we wait for POC before working on payment method definition?
jalpesh: I think we should do a
POC first
... I am still trying to convince myself of the benefit of the
proposal compared to current implementation
Jonathan: +1 to waiting for a POC before starting work on a specification; I think we need to validate the architecture
IJ: Will PSP and SRCI usually be the same?
crallen_: The way that this proposal is written, it seems that the merchant would have to identify the SRCI. As opposed to a "preference"
IJ: What is SRCI if unavailable?
Tomasz: We've not gone into that
in the proposal. The focus is on the ability to specify the
SRCI
... The SRCI could nominate itself to host the transaction in
the payment handler window
<scribe> ACTION: Ian to raise issue on proposal about whether merchant "pref" or something else re: SRCI
(Editor's note: see issue 40)
IJ: What are the use cases that validate the decoupling?
Tomasz: I think we should
maintain flexibility.
... as there are different integration models
... e.g., SDK provides library to merchant
... that's one model we want to cover
... but we may also want to offer greater flexibility for
merchants that want to leverage the PR API directly
... we also have hasEnrolledINstrument functionality that can
verify if an SRCI can support a given transaction.
... before show() is called
jalpesh: You are basically
talking about 2 use cases: (1) PSP renders UX (2) Merchant is
rendering UX
... in scenario 2, wouldn't the merchant provide their own URL?
They might delegate that to another system, but it's not quite
decoupling
Tomasz: What I have in mind is
that we may have a merchant who calls PR API and uses the PSP
under the hood to process the credential.
... the payment handler experience is provided by the SRCI
Jalpesh: Let's assume that there are 2 payment patterns without Payment Request: PSP does UX or merchant does UX. I am hearing a third use case where merchant delegates experience to payment app where SRCI handles display
<scribe> ACTION: Tomasz to edit the proposed architecture document multiple integration models
10 June
Payments and Authentication: Driving toward a Whole Greater than Parts
Tomasz: How will we proceed with the definition of the payment method, assuming we'll have a POC.
(IJ goes through process)
IJ: Any other reviews or new thoughts?
Jalpesh: I made some edits to the
architecture document.
<scribe> ACTION: Ian to review new text from Jalpesh (Native Support for Payment Method Into the Browser)
<scribe> ACTION: Tomasz to review new text from Jalpesh
ADJOURNED