Re: [w3c/3ds] 3DS 2.0 specificities by schema (#1)

@marcoscaceres 

I've added a new [chapter](https://github.com/lyra-labs/poc-w3c-webpayments/wiki/3DSecure-and-PRAPI#fully-generic-proposal-detailled-flow) trying to answer your questions.

It starts giving precision in the [diagram flow](https://github.com/lyra-labs/poc-w3c-webpayments/blob/master/sequence-diagram-PRAPI-3DS2-proposal-with-domain.png).

Using sample implementation provided on [https://demostore-webpaymentapi-demo.lyra-labs.fr/](https://demostore-webpaymentapi-demo.lyra-labs.fr/), we can illustrate user interactions:
1. User ask for [checkout](https://github.com/lyra-labs/poc-w3c-webpayments/blob/master/demo-screens/1-merchant-checkout.png).
2. Thru browser Payment Request API, user [select payment mean](https://github.com/lyra-labs/poc-w3c-webpayments/blob/master/demo-screens/2-payment-handler-card-selection.png), a registered card in our demonstration.
3. Thru Payment Handler, user fill [CVC value](https://github.com/lyra-labs/poc-w3c-webpayments/blob/master/demo-screens/3-payment-handler-cvc.png).
4. Thereafter, [payment authentication](https://github.com/lyra-labs/poc-w3c-webpayments/blob/master/demo-screens/4-payment-handler-authentication-using-delegation.png) is delegated to the bank by Payment Handler.
5. Finally, [payment is done](https://github.com/lyra-labs/poc-w3c-webpayments/blob/master/demo-screens/5-payment-done.png) and confirmed thru Payment Request API.

@stpeter 

1. It depends if authentication is managed by a Payment Handler or is managed transversely to one or more Payment Handlers. In first case, the mediator doesn't need to know that information before Payment Handler selection, in such case that information should be a Payment Handler parameter. In second case, it should be slightly different and requires to go ahead in a discussion following that direction.
2. Very good point, it requires me to add an interaction between payment handler and merchant backed to realize server authentication decision. After correction, the answer is yes, the merchant have to indicate the number of article to its 3DS server before to generate the AReq message. In the [updated flow](https://github.com/lyra-labs/poc-w3c-webpayments/blob/master/sequence-diagram-PRAPI-3DS2-proposal-with-domain.png), that information should be transmitted when payment handler ask merchant backend for authentication decision.
3. Carte Bancaire is a schema, similarly to VISA, MasterCard, AMEX, JCB, Diners.... In my opinion it is neither "an Authentication Provider" because it is the role of issuing bank, neither a "Payment Handler" (as basic-card) that can manage more than one schema at one time. To go back to 3DS, Carte Bancaire will have it's own Directory Server similarly to other schemes. The risk analysis score is communicated to the authentication provider (bank.com issuer) in the AReq message to help him to make a decision according authentication decision. That score is calculated and added in the AReq flow by the Directory Server not represented in preceding schema.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/3ds/issues/1#issuecomment-360428852