Here's an outline of my thoughts after reviewing the draft spec. I'll close this issue after we discuss these at today's meeting.

Request data
- requestLevel cases
  separate into two things: is 3ds required? is challenge required/not allowed/don't care?
    merchant likely doesn't know which until address entered
  references to "step up" should be changed to "challenge flow", which is the official 3DS spec term
- handler for 3DS will need to receive or collect shipping address for physical goods
  merchant needs a way to mark whether shipping is needed or not
  merchant needs events to listen on shipping changes and possibly change 3DS config
  where do we specify "stuff the 3DS module requires of its host payment method?"
- handler will need to gather email and 
- payee data
  order number, merchant id, acquirer id, acquirer merchant id, merchant name, 
  opt in to encrypted or tokenized card number


Response data
- cases of ThreeDSResponse
  (See Cardinal's 3DS2 result test cases at https://cardinaldocs.atlassian.net/wiki/spaces/CCen/pages/412712961/3DS+2.0+Test+Cases)
  if we add a requestLevel=never3DS, then returned data shape is different
    is the shape of returned data then specified by the host payment method?
  if there's an error during 3ds, or ACS is unavailable or times out
    if 3ds required, handler should prompt for another form of payment
    if 3ds not required, handler maybe falls back to returnign card/token without performing 3ds.
  there are lots of case intersections, for example:
    if 3ds is required but merchant specifies frictionless, what do we do if frictionless denied?
      give up and ask for another payment method from the customer?
      try 3ds again and allow a challenge?

Privacy/data gathering
- points in the spec still stand: we don't know what to do here, probably need browsers to make a suggestion
- how we will load method_url, or get around the need to, is the biggest question for this spec

Footnote
- Should 3DS reference point to a specific version of the spec rather than a landing page that will point to the latest 3DS-related specs and change over time?

Hi all,

Based on discussion at the Singapore face-to-face meeting, @marcoscaceres articulated some wishes to get a better picture of how to connect 3DS with payment request. With his permission, I copy his notes here for discussion.

======
From @marcoscaceres:

Following up from the w3c face to face meeting, basically what we need is either test HTTP endpoints or JSON responses for (apologies, I don't know the precise terminology for these - or if I'm missing
steps):

1. A URL that the merchant provides to the Payment Request API for the 3DS verification (I can fake this, if I have fake data - below).
2. The shape (e.g., JSON) of the payload that the browser sends to the verification URL (this is the finger print bit - but the browser will generate something representing the user fingerprint).
3. A "verified" response; a "rejected" response; or any other kind of response as .json.
4. The response for "step up" verification - so we can generate the UI within the browser (please, NOT the HTML! pretend it's a native application - so JSON).
5. When step up is done, the rejected response and/ the authenticated response.
6. The data that the browser would then return to the merchant.

The example in the spec has a requestLevel field in the data object within the Payment Request methodData. Can this field be "mixed in" with any arbitrary payment method (basic-card, tokenized-card, SEPA, Interledger, etc.)?

What if the merchant or network wants to require a 3DS flow for some payment methods (say, basic-card) but not others (say, SEPA)?

And is requestLevel too generic (i.e., would something like authRequestLevel or 3DSRequestLevel be clearer)?

3DS supports no-friction flows and merchants may even accept a liability shift in order to have zero friction flows. Risk engines today fingerprint the browser and determine whether a frictionless flow suffices. Changes in browsers are (by design) going to make the fingerprinting more difficult.

WebAuthn supports low-friction, but not no-friction flows.

What browser capabilities could support no-friction flows without adding to the fingerprinting surface?

See some previous discussion about browser-generated IDs:
https://www.w3.org/2019/Talks/ij_risk_20190808/index.html?full#10

[This is a super rough draft! Comments/revisions/rewrites very welcome.]

The goal of this task force is to create browser standards that allow the authentication of online credit card payments.

• Customers want a convenient way to complete online purchases that they know they can trust.
• Merchants want to comply with new Secure Customer Authentication standards (e.g. in India and the EU), but still want to minimize the friction and conversion rate impact of extra authentication in their checkout flows.
• PSPs want to make their existing products (like UIs to accept and tokenize card numbers) comply with SCA rules, while retaining enough control to still offer distinguishing features or UI innovations.
• Issuers want additional data about transactions to inform their risk models and offer value-added services to their cardholders. (They also wouldn't mind if their name/logo appeared prominently during the payment flow.)
• Browser authors want to offer better web payment options to help web commerce continue to grow. But they act on behalf of users and are therefore wary of sharing personal data or executing third-party code without explicit permission. Browser authors are generally not part of the payments world and are reluctant to take on responsibility for payments-specific data or policies that may change over time.

At the 27 June 3DS task force call, we briefly discussed the idea of explicitly mentioning user agent support for a user preference for strong authentication, which presumably would mean less data exposure and thus useful for those with strong privacy preferences.

@stpeter suggested we gather more information about the range of user preferences before specifying a feature (e.g., it may not be useful to have a simple on/off switch).

In regards to the draft spec's requestLevel member, I would recommend:

• Adding a third value to reflect that the merchant absolutely does not want 3ds to occur
• Adding a method to allow the merchant to update the requestLevel in response to payment sheet events like shipping address changes.

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.

I'm posting some flow diagrams and rough thoughts here so that they can be seen publicly during tomorrow's call. These diagrams leave out a lot of detail and are incorrect in some details. But I'm trying to make a few points about how, even at a very coarse level of detail, there are some conflicts between them that we need to work out before starting to think of a strategy for moving forward.

Also note that these thoughts so far seem pretty negative, since they mostly point out challenges rather than solutions. But I'm actually super excited to try to find solutions: I just want to point out the challenges so we can start tackling them right away.

3DS2 101

PRAPI 101

Some fundamental issues

• We can't obviously push complexity to payment handlers because merchants cannot simply work with any handler that registers for that generic 3DS method. Nor can they hand over all the data involved to an unknown middleman that speaks to the 3DS server for them.
• But we also can't push it onto the browsers, because they probably won't want to own things like complying with the tiny details of annually-changing payments industry specifications that they have no involvement with.

How to resolve these issues?

So what can the WPWG do to make 3DS compliance easier on merchants while requiring only a reasonable level of browser involvement? I see a couple directions but also problems with each of them:

• Specify a payment method that allows the merchant to pick a specific 3DS server. The 3DS server could then implement a payment handler that is installed on-demand, but it wouldn't have access to the merchant page to actually fulfill the web flow...
• Adopt the native flow so that the challenge can be handled by a payment app. But then every 3DS server needs its own native app which needs to be pre-installed for it to be useful to a customer trying to buy from a merchant... (And makes this spec only work on mobile platforms, hobbling it as a "web" standard, which is a problem.)
• Specify a 3DS payment method where handlers are the issuing banks, who are likely to already have an app installed on many of their customers' devices. But then how do all the flows that normally go through the 3DS server and card network happen between the merchant and issuer via PRAPI ...? (And makes this spec only work on mobile platforms, hobbling it as a "web" standard, which is a problem.)
• Propose 3DS2 protocol tweaks that would make it easier for browsers to implement without the security concerns of iframes. (Targeting a future version which will be in force when EU SCA laws come into force and when browser implementations will be ready.)

At yesterday's 3DS task force call [1], it was suggested that if a browser or third party payment handler initiates 3DS flows, it may be necessary to include additional data (above and beyond token data, for example) in the response, namely: 3DS crypto and XID data.

This issue is a place-holder for that discussion.

Ian

[1] https://www.w3.org/2018/02/27-wpwg-minutes.html