Card Payment Security Task Force

<scribe> Scribe: Ian

Launch of Web Payment Security IG

https://www.w3.org/2019/03/pressrelease-wps.html.en

<DannyWP> bravo!

SRC payment method structure

[Ian summary]

- If a user has a card, they need to be able to pay

<scribe> ...new browser capability: default payment handler(s)

IJ: Chrome indicated interest in this topic, offering a default

stpeter: I will need to absorb, but in principle doesn't seem like a horrible idea

- Can we postpone user experience detail: how much friction before user gets it?

Jonathan: I think it's critical to understand how the user is redirected to the default payment handler, and how consent is provided

IJ: We should seek the least friction possible; but let's defer

Jalpesh: I am hearing from Ian (1) keep issue on back burner (2) may be implementation detail

IJ: I don't yet know what needs to be standardized
... e.g., "SHOULD provide access to a default"

Jalpesh: Has to be a MUST.

IJ: Payment method spec is for the payment handler to implement
... This is behavior that we want across all payment methods, so not specific to SRC

Jalpesh: Any mediator that implements a standardized payment method should do a default behavior.
... I think it's payment method specific.
... Let's do it for SRC and learn from there.

Jonathan: Next step is to check with browsers, right?

Ian: I would suggest we begin to write down the payment method and socialize it.

Jalpesh: We are saying "If you implement SRC, you need to support a default."

https://github.com/w3c/src/

https://w3c.github.io/3ds/index.html

https://github.com/w3c/src/wiki

IJ: Send me your GitHub nick for write access

Q. Is one or more registries of certified DCF / Payment handlers required?

scribe: or not desired.

<DannyWP> DannyRussellWP - github

IJ: 0, 1, or N registries?
... the registry would be the manifest
... but Jalpesh indicated "preference for no manifest"

Jalpesh: We don't have an origin for hosting an SRC origin
... we want common acceptance
... don't want specific network manifests
... EMV would not host it
... the implication of having no registry is chrome managing a white or blacklist
... and managing the UX of having multiple matching payment handlers

Dean: What about hosting it on w3.org?

Jalpesh: That did come up in discussion...but there are server traffic issues...

Dean: That's an implementation detail; you would use caching

IJ: Risk is card skimming if you don't have a white list

<scribe> ACTION: Ian to write down the considerations on these topics whitelist, blacklist

<trackbot> 'Ian' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., IFSF-EFT-WG-Lead, ijacobs).

Jalpesh: One of the considerations is to call out, in the current scenario, what user agents are concretely impacted today
... e.g,. if payment handlers supported
... if src supported
... if user has choice of payment handler
... overriding default on a system that allows more than one payment handler

- short string v. URL

IJ: I feel we can postpone that topic...once we know what we want in terms of registry or default

Sachin: Short string could be translated into URL

Jalpesh: I don't like the URL approach

Sachin: Let's separate the concept from implementation. One is there needs to be an identifier. The second is there needs to be a mechanism to resolve the payment method into some sort of registry.
... there may be a requirement to have a hosted information site

IJ: Agree we need to resolve the registry, default question first.

Jalpesh: Let the implementations adjust to the preferred approach based on our requirements

[Sachin leaves]

Short string implications:

- Browser implements (or delegates)

- Any payment handler possible

- Browser black list

URL implications:

- Browser not likely to implement

- Payment method manifest white lists

- Browser black list

Jalpesh: I liked the idea of translating 'src' to a URL.
... could be Chrome specific
... let's solve for those constraints in isolation

[Data model]

IJ: Next steps? Talk here or move to a wiki in drafty form?

Jonathan: Goal is data model conforms to SRC specs

<scribe> ACTION: Ian to move Jonathan's data model to the SRC wiki, clearly labeled as EARLY DRAFT

<trackbot> 'Ian' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., IFSF-EFT-WG-Lead, ijacobs).

Next meeting

IJ: I propose to make doc available by 25 April, for discussion at 1 May task force call

Jalpesh: +1

IJ: What are the parameters (e.g., around 3DS and tokenization)?
... can you ask for a basic card response or do you always get a tokenized response?

<DannyWP> dropping off

Jonathan: We would not support returning basic card data.

Jalpesh: 3DS / auth needs to be there.

IJ: I imagine a single payment method (SRC) with parameters.
... one param relates to auth of credentials.

Jalpesh: Regarding "token" or "basic card" .... that might be something of a configuration at a merchant level.
... Let's call it "always token" where the cryptogram might be optional.