3DS 2.0 specificities by schema

[glelouarn]

CB schema (Carte Bancaire in France) latest communication identify following specificities:

1. Merchant have the opportunity to express a wish according cardholder authentication. Going back to https://raw.githubusercontent.com/lyra-labs/poc-w3c-webpayments/master/sequence-diagram-PRAPI-3DS2-proposal.png, that information should be known when mediator hand-over control payment handler.
2. During AREQ flow, using extension mechanism of 3DS 2.0 protocol, merchant have to indicate the number of article bought.
3. During ARES flow, using extension mechanism of 3DS 2.0 protocol, CB DS will add a risk analysis score in the message.

Should be interesting to identify specificities for other schemas.

[marcoscaceres]

I'm having difficulty following these flow diagrams 😢 Would be really helpful to add dummy URLs, so browser folks can rationalize this in terms of "origins", which helps us understand how it would interface with the web security model and the javascript contexts in which this would need to run.

Alternatively, it might be good to show the flow using a real website and maybe using screeshots from Chromes' Payment UI?

Note that if at any point something goes from sitaA.com to siteB.com, the javascript context is blown away (as is the payment request).

[stpeter]

Regarding (1) - by "that information should be known when mediator hand-over control payment handler" do we mean that the mediator needs to know before the handover? If so, how does the mediator know this and who tells the mediator this is necessary? (In terms of https://raw.githubusercontent.com/lyra-labs/poc-w3c-webpayments/master/sequence-diagram-PRAPI-3DS2-proposal.png I'm trying to figure out the process.)

Regarding (2) - when you say "merchant have to indicate the number of article bought", to whom does the merchant communicate this information in the Authentication Request (AReq) flow? The 3DS specification says "The 3DS Server forms the AReq message when requesting authentication of the Cardholder." Does the merchant need to communicate the number of articles bought to the 3DS Server before the server generates the AReq message? (And what about the value of the items or other information?)

Regarding (3) - per https://raw.githubusercontent.com/lyra-labs/poc-w3c-webpayments/master/sequence-diagram-PRAPI-3DS2-proposal.png is Carte Bancaire an "Authentication Provider" or a "Payment Handler"? To whom is the risk analysis score communicated (e.g., to the merchant) in the Authentication Response (ARes) flow?

[glelouarn]

@marcoscaceres

I've added a new chapter trying to answer your questions.

It starts giving precision in the diagram flow.

Using sample implementation provided on https://demostore-webpaymentapi-demo.lyra-labs.fr/, we can illustrate user interactions:

1. User ask for checkout.
2. Thru browser Payment Request API, user select payment mean, a registered card in our demonstration.
3. Thru Payment Handler, user fill CVC value.
4. Thereafter, payment authentication is delegated to the bank by Payment Handler.
5. Finally, payment is done 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, 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.

[marcoscaceres]

4. Thereafter, payment authentication is delegated to the bank by Payment Handler.

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.

So, help me understand this (I'm still not getting the following from the diagram):

• 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?

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

[stpeter]

@marcoscaceres 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. :-)

[stpeter]

@glelouarn Regarding the "Fully generic proposal", I have two questions:

1. 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).

2. 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).

[glelouarn]

@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 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.

[asolove-stripe]

One thought worth considering: because of the cross-domain problems with displaying html from the issuer, we might consider allowing implementations to use the native client option rather than the web client. Using a native challenge flow would let the implementer of the payment handler use the API-based challenge with its own UI, rather than having to display arbitrary html from the issuer.

[glelouarn]

Fully agree with you Adam but in such case, it remains some tricky questions. Specification from EMVCo concerning native client is there and there:

• According that specification, the native client shall be able to output native components or HTML content, in such case we still have cross domain issue.
• That SDK should be certified, as a consequence who will develop it: agent providers, networks, third parties, merchant using third providers?

I share the point of view we need a standardized native implementation to integrate 3DS in browser but according my current knowledge of 3DS 2.1 specification, I can't figure out how to do it without 3DS specification updates.

The question can be, should we look for a solution compliant with 3DS 2.1 or could we envisage a solution based one an evolution of the current 2.1 specifications?

[asolove-stripe]

My assumption has been that browsers themselves are not going to implement this method. It's too complicated for them to want to own.

Rather, I've assumed we're writing a spec that would allow native apps to implement the method and then be usable interoperably from the browser. In that case, it's easy to imagine the card companies or PSPs implementing (or licensing access to) a validated native SDK and using that to fulfill web payment requests.

[ianbjacobs]

@marcoscaceres wrote: "It seems like you are navigating the payment sheet to another domain (like you are showing an iframe). Browser's won't do that."

I would like to get a better understanding of that.

In this case, the browser has handed control to the payment handler. The payment handler may open a window [1] for user interaction; now we are no longer in the sheet we are in a payment handler controlled window. I believe that in the call to open the window, the origin of the new browsing context has to be the same as that of the payment handler (service worker). Questions:

• Can the user navigate to another origin within that window (e.g., via a link)?
• Can the payment handler include content from another origin (e.g., in an iframe)?
• Can the payment handler open another window (e.g., for authentication by another origin such as bank.com in [2])?

I don't know enough about the origin requirements/limitations related to the payment handler window. Also, it seems we want to reuse the service worker open window algorithm [3] and I know even less about that.

Also, are there any relevant learnings from Web Authentication [4]?

Ian

[1] https://w3c.github.io/payment-handler/#dfn-open-window-algorithm
[2] https://github.com/lyra-labs/poc-w3c-webpayments/blob/master/sequence-diagram-PRAPI-3DS2-proposal-with-domain.png
[3] https://www.w3.org/TR/service-workers-1/#clients-openwindow
[4] https://www.w3.org/TR/webauthn/

[romandev]

Can the user navigate to another origin within that window (e.g., via a link)?

Sure, the user can navigate any origin including clicking a link.
But if the origin is out of scope, the SW can not control the window anymore.

Can the payment handler include content from another origin (e.g., in an iframe)?

The payment handler's window includes an iframe from another origin but the associated SW can not control it.

Can the payment handler open another window (e.g., for authentication by another origin such as bank.com in [2])?

The payment handler can open any origin's window. But it might not be controlled by the associated SW.

I'm on a trip. So, I couldn't test it actually but I believe the following scenario will be possible.

1. Open payment handler's window (pay.com)
2. Navigate to bank.com
3. Process authentication on bank.com
4. Back to payment handler's origin. Then the window will be controlled by SW again.

[marcoscaceres]

I wrote:

"It seems like you are navigating the payment sheet to another domain (like you are showing an iframe). Browser's won't do that."

Let me clarify - the payment sheet displayed to the user is a "privileged security context": we cannot insert any iframes or html into it. Think of it like a native app - you can pass it data (e.g., JSON or an IDL Dictionary), but definitely not HTML, and definitely can't display an iframe.

In this case, the browser has handed control to the payment handler. The payment handler may open a window [1] for user interaction;

@ianbjacobs, @romandev, respectfully, I would like us to work through this without bringing in the Payment Request API or any API (we are not there yet, but soon!) - let's focus on the core use case of what we want to solve from a user-flow/user experience perspective. Thus, Let's put PR API aside and focus on Basic Card (not the API, but just on "I have a credit card, I wanna buy a thing!"), as 3DS has most immediate relevance there.

If we are just going to be opening new windows/tabs, etc. then they user experience is going to be confusing to users (and no better than what we have today!). Ideally, we want the payment sheet to perform the 3DS second factor authentication, right?

@glelouarn, wrote:

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

Ok, there are two options here:

1. the merchant can pass the URL.
2. the browser could hold something like https://www.bindb.com, no? We already need to ship a subset of that to identify the type of card (i.e., "is it credit, debit, prepaid? what's the network?" ) .

You are correct that 1 (merchant passes the URL) would be easier, and it's already what is expected by 3DS, right?

So, let's continue from here:

1. Does the merchant need to be holding the user's credit card number to determine the 3DS URL?

[glelouarn]

@marcoscaceres

Sure I share that one merchant passes the URL would be easier, main difficulty is the fact that URL depends on the card (brand, type...). As a consequence:

Does the merchant need to be holding the user's credit card number to determine the 3DS URL?

Yes, merchant ask method URL asking it to the Directory Server of the brand passing it the card number.

[marcoscaceres]

Sorry, another naive question from me:

• what would happen if, instead, the merchant passed the "Directory Server" URL to the payment sheet? The browser already knows the brand and the BIN of the card - so it could, upon the user hitting "Pay", communicate with to the "Directory Server" on behalf of the merchant.

Put differently, could the browser ping the "Directory Server", get the authorization URL, and then perform the second factor authentication on behalf of the merchant?

[glelouarn]

Sure your question have sense. Looking at EMV CO 3DS 2.0 schema:

We see that only ACS "bank.com" and 3DS Server can interact with network DS using mutual authentication. 3DS Server is considered as a confident actor in the model, I'm not sure how it could be transcript to a model where 3DS Server role is managed by browser.

[stpeter]

Hey @marcoscaceres I found the EMVCo and UL webinars on 3-D Secure 2.0 to be helpful in understanding the 3DS architecture. The Directory Server is in the "interop domain" - essentially, it's a network entity that acts as a broker between the 3DS Server in the "merchant or acquirer domain" (likely run by a payment service provider) and the Access Control Server in the "issuer domain". As far as I can see, architecturally it doesn't make sense for the browser to communicate directly with the Directory Server.

[marcoscaceres]

Spent the whole day watching 3DS 2.0 videos... this is basically me now: https://www.youtube.com/watch?v=6vMO3XmNXe4

[ianbjacobs]

I watched 3DS videos as well over the weekend. And I watched WebAuthn videos yesterday. :)
Ian