Re: Sanity check on API using flows from Flows Task Force

No, I'm not attending, but Jean-Yves and Cyril who know very well the 
context will attend.
I'm going to propose the following (and Cyril is writing a document to 
explain it more deeply):

As DSP2 creates the PISP,
- there are 2 ways the PISP can get into the system either
     - as the PISP of the Merchant (many German sites redirect to SOFORT 
in that logic)
     - or as the PISP of the Shopper: this is the most disruptive 
situation, because it means that the Shopper's bank loses its 
prerogative of payment initiator
      (in addition, a consumer could have many PISP, a preferred one to 
this type of transaction, another preferred one for another type...)
- in both cases, the PISP would manage the initiation dialog and send to 
the Account servicing provider (which does the job done today by a bank) 
of the Shopper a real-time transfer initiation message; in return it 
would get a report or status message: "OK your transfer is fine".
Then the API could to its complete job.
...
This discussion should be related to a mail sent by Ian quite a while ago.
The title of his mail was: "On a PISP flow [Was: Feedback from Harry 
Halpin and Ian Jacobs to European Banking  Authority Discussion Paper]"
And here is the content:
"

/Hi Frédéric, Here’s our “flow” home page: //https://github.com/w3c/webpayments/wiki/Flows//The exercise should help us understand the impact of the Web Payment 
APIs on priority flows, and in looking at the “before the API” and 
“after the API” pictures, we are like to detect issues that we need to 
ensure we address in the API specification. Similarly, it seems through 
your question that there’s a way to use (different) flows to show the 
world “before PISPs” and “with PISPs”. I don’t know whether PISPs will 
have an impact on all the flows that are listed on the above wiki page. 
But in the cases where PISPs do play a role, I think it makes sense to 
do something like this: * Take a “pre W3C API flow” and modify it to 
include a PISP * Add it to the list of flows (e.g., “3DS with PISP” 
though that may or may not be a real example). * Create a “post W3C API 
flow” (e.g., 3DS with PISP and W3C API”). Then we can evaluate the 
result and see if we observe any critical issues that the W3C API needs 
to take into account. If you would like to contribute, I suggest 
contacting Nick Telford-Reed and Matt Saxon on the working group list: //public-payments-wg@w3.org//. Thanks! Ian/

"


T
>
> There is indeed a real problem when we try to apply the API to the SCT:
>
> 1/ The basic logic of the SCT does not work with a web API
>
> -SCT is mainly a batch flow (it's quite difficult to say that such a 
> flow is managed by a payment app)
>
> -For that reason, it is impossible to embrace the flow in a browser 
> logic: the API cannot consider that:
>
> o// once this is called, Steps #3-#12 are executed by the payment app
>
> -The SCT flow represented in PlantUML shows a shopper who quits the 
> Merchant website to go to his home banking to order his transfer.
>
> -This is why the API has no work to do…
>
> 2/ The API should be applied to a reconfigured SCT flow
>
> Some PSP propose a webized SCT: this is done by turning into real-time 
> flows Steps 9 and 10 (transfer initiation and report). This allows to 
> have a fluid real-time process by embedding all the shopper dialog of 
> initiation in one "frame".
>
> This flow becomes especially important when we introduce the new 
> entity created by PSD2, e.g. the Payment Initiation Service Provider.
>
> The rest of the process (inter-bank clearing and notification) remains 
> based on batch flows triggered later.
>
> But the flow logic has to be drawn differently to represent this case. 
> (I a preparing a new document, which makes the link between this 
> problem and the emergence of Payment Initiation Service Providers will 
> present such flows; Cf. "PISP under PSD2 - SCT flows - Merchant 
> PISP.pml" and "PISP under PSD2 - SCT flows - Shopper PISP.pml").
>
> 3/ The authentication framework is absent
>
> But then remains the biggest part of the problem, which is the 
> authentication methodology.
>
> A difference between a card and an SCT is that a card includes an 
> authentication mechanism, while a transfer does not.
>
> A consumer who enters his IBAN on a "transfer HTML page" is not at all 
> doing a "strong authentication".
>
> And the PSP site who sends the resulting message to the shopper's bank 
> has no way to prove to the bank that it was the authentic customer who 
> made this operation.
>
> No regulatory instance defined a methodology to solve this…Which means 
> that there is, at present, no standard for a e-SCT.
>
> This is where Cyril's proposal (SCAI) comes to address this big 
> shortcoming.
>
> By providing a "generic" framework of authentication for any payment 
> instrument in the initiation phase, it makes it possible to create a 
> e-SCT based on:
>
> -Real-time messages
>
> -A flow logic embedding the authentication data between the 3 actors 
> of the initiation: Bank of the shopper, Shopper, and PSP of the Merchant.
>
> s 


Le 17/02/2016 13:38, Matt Saxon a écrit :
>
> Great, do you think you might have the SOFORT flow documented in time 
> for next week’s f2f – are you attending?
>
> *From:*Frédéric Meignien [mailto:frederic.meignien@cantonconsulting.fr]
> *Sent:* 17 February 2016 12:25
> *To:* Matt Saxon; 'Manu Sporny'; 'Web Payments WG'
> *Cc:* 'VIGNET cyril'; 'Jean-Yves Rossi'; 'Paddy Ramanathan'; 
> 'evert.fekkes@rabobank.nl'; 'David Ezell'
> *Subject:* Re: Sanity check on API using flows from Flows Task Force
>
> Matt,
> I absolutely agree with what your propose hereunder (return a pending...).
>
> As regards the PISP, that's already a problem: for example, a quite 
> successful PSP in Germany, SOFORT, proposes to pay by transfer, and it 
> is of broad use among the shoppers. And the problem is that (strong) 
> authentication is not thoroughly satisfied at present. SOFRT is 
> nothing but a PISP...And the PSD2 is catching up with the realities of 
> the market.
> In the very next future, paying by transfer should be much more 
> widespread than today.
> Regards,
> Fred.
>
> Le 17/02/2016 12:59, Matt Saxon a écrit :
>
>     Fred,
>
>     Thanks for the observations, I agree with them.
>
>     However it should be noted that the Flows as documented by the
>     Flows Taskforce are current flows in use in the wild, the PISP,
>     PSD2 flows are future flows. We need to address both as we can
>     assume that everyone will have migrated to the new flows IMO.
>
>     I believe the current flow should  be handled by allowing the API
>     to return a ‘pending settlement’ status or similar so the merchant
>     can wait for the async notification before providing the agreed
>     services.
>
>     Regards,
>
>     Matt.
>
>     *From:*Frédéric Meignien
>     [mailto:frederic.meignien@cantonconsulting.fr]
>     *Sent:* 17 February 2016 11:38
>     *To:* Manu Sporny; Web Payments WG
>     *Cc:* VIGNET cyril; Jean-Yves Rossi; Paddy Ramanathan;
>     evert.fekkes@rabobank.nl <mailto:evert.fekkes@rabobank.nl>; David
>     Ezell
>     *Subject:* Re: Sanity check on API using flows from Flows Task Force
>
>     Hello,
>
>     There is indeed a real problem when we try to apply the API to the
>     SCT:
>
>     1/ The basic logic of the SCT does not work with a web API
>
>     -SCT is mainly a batch flow (it's quite difficult to say that such
>     a flow is managed by a payment app)
>
>     -For that reason, it is impossible to embrace the flow in a
>     browser logic: the API cannot consider that:
>
>     o// once this is called, Steps #3-#12 are executed by the payment app
>
>
>     in fact, the process is interrupted when the transfer initiation
>     message is done.
>
>
>     -That is why the SCT flow represented in PlantUML in GitHub shows
>     a shopper who quits the Merchant website to go to his home banking
>     to order his transfer.
>
>     -This is why the API has no work to do…
>
>     2/ The API should be applied to a reconfigured SCT flow
>
>     Some PSP propose a webized SCT: this is done by turning into
>     real-time flows Steps 9 and 10 (transfer initiation and report).
>     This allows to have a fluid real-time process by embedding all the
>     shopper dialog of initiation in one "frame".
>
>     This flow becomes especially important when we introduce the new
>     entity created by PSD2, e.g. the Payment Initiation Service Provider.
>
>     The rest of the process (inter-bank clearing and notification)
>     remains based on batch flows triggered later.
>
>     But the flow logic has to be drawn differently to represent this
>     case. (I a preparing a new document, which makes the link between
>     this problem and the emergence of Payment Initiation Service
>     Providers will present such flows; Cf. "PISP under PSD2 - SCT
>     flows - Merchant PISP.pml" and "PISP under PSD2 - SCT flows -
>     Shopper PISP.pml").
>
>     3/ The authentication framework is absent
>
>     But then remains the biggest part of the problem, which is the
>     authentication methodology.
>
>     A difference between a card and an SCT is that a card includes an
>     authentication mechanism, while a transfer does not.
>
>     A consumer who enters his IBAN on a "transfer HTML page" is not at
>     all doing a "strong authentication".
>
>     And the PSP site who sends the resulting message to the shopper's
>     bank has no way to prove to the bank that it was the authentic
>     customer who made this operation.
>
>     No regulatory instance defined a methodology to solve this…Which
>     means that there is, at present, no standard for a e-SCT.
>
>     This is where Cyril's proposal (SCAI) comes to address this big
>     shortcoming.
>
>     By providing a "generic" framework of authentication for any
>     payment instrument in the initiation phase, it makes it possible
>     to create a e-SCT based on:
>
>     -Real-time messages
>
>     -A flow logic embedding the authentication data between the 3
>     actors of the initiation: Bank of the shopper, Shopper, and PSP of
>     the Merchant.
>
>     Le 12/02/2016 23:51, Manu Sporny a écrit :
>
>         Hi Matt and the rest of the Flows Task Force,
>
>           
>
>         In order to get a sanity check on the Web Payments CG Browser API
>
>         proposal, we've started checking the API against the flows that the
>
>         Flows Task Force has been working on. We're doing this by writing code
>
>         that uses the payments API to match the flows. The result can be found here:
>
>           
>
>         http://wicg.github.io/web-payments-browser-api/#flows-addendum
>
>           
>
>         We've integrated the legacy card, tokenized card, SEPA Credit Transfer,
>
>         and basic Bitcoin flows for now. The good news is that there is very
>
>         little variation between each payment scheme so far (which demonstrates
>
>         that the API is fairly generic, which is a good thing).
>
>           
>
>         We'd be interested in your feedback. For example, we think we've made a
>
>         mistake in the PSP-mediated SEPA Credit Transfer use case, but can't
>
>         quite figure out where.
>
>           
>
>         In any case, just a heads up that we've started integrating the flows
>
>         and apologies for taking so long to get around to this.
>
>           
>
>         -- manu
>
>           
>
>     ------------------------------------------------------------------------
>
>     Avast logo <https://www.avast.com/antivirus>
>
>      
>
>     This email has been checked for viruses by Avast antivirus software.
>     www.avast.com <https://www.avast.com/antivirus>
>
>
>
> ------------------------------------------------------------------------
> Avast logo <https://www.avast.com/antivirus>  
>
> This email has been checked for viruses by Avast antivirus software.
> www.avast.com <https://www.avast.com/antivirus>
>
>