Jonathan: We reviewed Jalpesh's
flows; he made some minor modifications based on the
discussion. There were many good questions (reflected in
the minutes). At TPAC we will show demos to illustrate these flows:
... first time user adding a card
... returning user on the same device
... the demo will go further by illustrating the date exchanged
through PR API
... we did not have time to go through the 3DS flows last week. As part of SRC, if 3DS is invoked what does
it look like? Tomasz can speak to that
(e.g., invoked by merchant, payment handler, SRC system on
behalf of others, etc.)
... Tomasz can show one view of that
... also, a month ago there was a request that we find a way to
leverage 3DS outside of SRC
... we don't have that today but we can also prepare that for
TPAC
... I suggest we go through the flows today with representation
of 3DS...we will add the flows in the next few days to
represent the other options
IJ: Do you think we should work
on 3DS outside of SRC as a priority? (See the previous work on a reusable 3DS module for different payment methods.)
... should we just start with SRC and then learn from that?
Jonathan: +1 to get the data flow
down
... if browsers can facilitate some 3DS experience, then I
think it can be done independent of SRC
Tomasz: This is also related to
where exactly the merchant declares that they want 3DS
facilitated by the payment handler
... so we could have this in the PR API request (at top level)
and it maps into the SRC payment method
... or we could include it in the SRC payment method
definition
AdrianHB: I had a call today with
somebody today who mentioned this topic explicitly. They were
wondering whether they could write a payment handler that does
basic card + 3DS
... so there may be use cases for this
Jonathan: It might come form the PSD2 regulation
IJ: Could we extract some of the good questions from last week's call into the payment method wiki?
<AdrianHB> Could we add some abstraction of the 3DS function to PR API? Something like a requestData where 3DS is an implementation of a service that can provide this?
Jonathan: We can add some
explanations from last week's call to the wiki
... idea of a FAQ is probably a good idea as well
<Ian> ACTION: Jonathan to send Ian some notes for text to integrate into the SRC wiki
[Tomasz shows flows]
Tomasz: First flow shows SRC
systems communicating with 3DS server.
... the 3DS system can be asked to facilitate 3DS on behalf of
merchant
... SRC system connects to issuing bank (via the directory
service [not shown])
... if the authentication request is Y or A, then auth is
frictionless.
... more interesting case is when the issuing bank specifies
the challenge flow
... the SRC payment handler would create a challenge window
(e.g., in an iframe if a web environment)
... then there's a challenge request to the issuing bank
... the challenge is submitted to the ACS, which sends back and
auth value
... then there is a request to close the challenge window in
the payment handler
... because the challenge flow was executed, the payment
handler needs to go back to the SRC system to complete checkout
and get the auth value and credentials
... all this is packed in the encrypted payload
... regarding the shape of the output data
Ian: We don't yet have specifics about the shape of the assurance data (see issue 16).
Tomasz: We can either include the assurance data (output from the 3DS auth) in the response from the SRC payment method, or we can elevate this into the PR API response.
Ian: I am hearing three options:
- 3DS parameters / response data as part of next version of PR API
- 3DS params / response data hardwired into SRC...but could also hardware other assurance methods into SR
- 3DS params/response data in separate module, and a payment method imports as many similar modules as it wants
Tomasz: We do have other assurance methods but we don't have specs for those yet
Brian: I think the goal should be
to define how 3DS works within PR API
... SRC payment handler may want to use it...there might be
some nuances to the SRC case
... but in general having 3DS work within PR API should be a
goal
... (as we previously discussed)
... there's also an SDK view of 3DS
IJ: I think there are
complexities to doing it at the PR API level due to encryption
(at least)
... feels more right to make 3DS a module that can be reused across different payment methods. The question is whether we have other use active use cases today beyond SRC.
mweksler: +1 to not overloading
PR API
... also, the "most engineered way" where there's an includable
module is a nice long-term approach
IJ: Today basic card is not supported in Firefox or Safari, so in practice we have N=1 use cases (SRC)
Brian: We should factor in "who
can initiate the call"
... could be merchant, or PSP (on the merchant side)
... could be some call-outs that "when I am initiating through
PR API" I would like to use 3DS
IJ: Do we need to figure out what to do in merchant-initiated 3DS flows?
Brian: There is a user experience
issue
... In payment handler scenario, the UX is built-in
PROPOSED: Continue to treat 3DS as a part of SRC; later if there is demand we look at factoring out 3DS as a reusable module for payment methods
<mweksler> +1
<AdrianHB> +1
<benoit> +1
<jv_> +1
<tomasz> +1
<Ian> ACTION: Ian to update the wiki to let people know that that is our current strategy
SRC is prominent on the day one agenda.
IJ: How should we allocate the 2 hours?
Jonathan: Start with demo (and
explain the differences since April)
... walk through identity management
... suggest 1 hour for that
IJ: Can we have a JSON response sample?
<scribe> ACTION: Tomasz to produce a sample JSON response data blob for SRC
(We conclude we don't need to walk through the issues list on low-level topics.)
<Ian> ACTION: Ian to look for someone to do an SRC v1 intro to the WG
In Japan!