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

@marcoscaceres 

> Ok, this is where it gets interesting. It seems like you are navigating the payment sheet to another domain (like you are showing an iframe). Browser's won't do that.

True, it is the major limitation with 3DS 1.0. Screenshoots I've provided for demonstration are based on an implementation of 3DS 1.0 and what you see is an iFrame displaying bank.com.

With [3DS 2.1](https://www.emvco.com/wp-content/plugins/pmpro-customizations/oy-getfile.php?u=/wp-content/uploads/documents/EMVCo_3DS_Spec_210_1017.pdf) it is slightly different because because protocol evolution doesn't requires anymore a redirection thru iFrame but requires exchanges between 3DS Client (merchant pages) and ACS (bank authentication pages) using CREQ/CRES messages (acsHTML element, page 234 of the specification). As a consequence, in my interpretation of the specification, merchant have to display content provided by cardholder bank and cross domain issue remain (3D means 3 Domain).

> Given a 3DS enabled Card (e.g., the MasterCard) - how did the browser get the verification URL? From the merchant? Or magically somehow from the bank?

Browser display merchant page who ask for the URL to the gateway who detect the card brand (e.g. MasterCard, AMEX, Visa, ...) and who ask it to the detected brand DS (Directory Server).

Simplest answer at a browser point of view is that it get the URL from the merchant.

> Must the 3DS iframe always be shown? Or is there some standardized RESTful interface for communication (or some other network channel)?

>From 3DS 2.0, it isn't an iFrame anymore but an HTML content coming from standardized messages (CReq for data entry and CRes for content to display). Note that there is also another way to integrate authentication using 3DS 2.0, it is using the SDK. Same messages CReq and CRes are used but rendering is done by the SDK native code displaying HTML content or structured content from CRes messages (see acsUiType parameter).

@stpeter 

>I believe that the flows described in the middle sections of the document were included only for the purpose of thinking through the problem, and that the "Fully generic proposal" at the end seems to be the result of that thinking. But @glelouarn can tell us for sure. :-)

You'r right, I've done it in that way because 3DS is complex and a lot of questions we will ask looking "Fully generic proposal" will find an answers in the 3DS flow details.

> How does the Payment Handler know that it needs to (optionally) request an authentication decision from the Merchant Backend? It seems that this would happen "behind the scenes" (i.e., no need for the Payment Handler to request this).

Requesting that information from the backend is mandatory for each transaction using 3DS 2.0. It is mandatory in the 3DS flow to ask to the backend who will ask to the network DS (Directory Server) how to continue decision.

As a consequence, if merchant integrate 3DS, that call is mandatory. Remember that in CB case we also need additional information provided by merchant indicating that even if using 3DS, he prefer to avoid authentication or not.

> For the authentication flow, is the Payment Handler always involved in talking with the Authentication Provider? It seems that the authentication flow might involve other entities or applications (e.g., SMS message, dedicated 2FA/MFA app).

Yes, it is the reason why CReq and CRes messages exist, to exchange authentication information between bank.com and merchant.

Yes again, that authentication flow involve other entities (SMS...) and is under the responsibility of bank.com.

It is complex and the reason why I think that a standardized integration of 3DS will be benefic for everybody:
- Merchant simplifying integration.
- Banks and schemes giving a better adoption of the technology.
- Customer with a more standard authentication flow.

-- 
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-361633314