Card Payment Security Task Force

ian: I'd like to discuss a Draft plan to get SRC to FPWD

ian: prompted by stpeter at the last call - a concrete plan to get a SRC payment method onto REC track
... I note up front that this payment method specification doesn't need to be owned by w3c; it could be EMVCo, for example
... I think it makes sense for W3C to start this work, but we can always revisit who manages the spec
... It would be great to have something to review at the face-to-face meeting, including for example the payment method identifier/URL
... then publish a FPWD after the F2F meeting (e.g. April)
... the rest of the plan wiki touches on some of the assumptions we've made
... We may have multiple payment method identifiers
... The discovery might be done by using the different URLS of different SRC systems
... We have not spent a lot of time yet on User ID friction
... we have mentioned the goal of reducing the firction, but we've not focussed on it yet
... There are some questions that I'd like to focus on today - including how we get appropriate resources on these
... The goal is to get to something that the industry can experiment with implementations
... and I welcome feedback

stpeter: the schedule overall looks good. Thanks for putting together. What is the expectation about W3C working on payment method specs generally?

ian: the medium term desire is that anyone can publish payment methods without additional browser engineering
... but we're not there yet
... perhaps we could ask the card network representatives for their views on the questions at the end of the plan wiki

ian: First, a quick recap of what's in a payment method spec (using Basic Card as an example). Typically, a payment method has an identifier, a data model, the inputs and outputs, and some algorithms to bind the method
... e.g. change of instrument
... one of the open questions is "what is the SRC method's identifier"?
... is it _one_ URL (in which case, there could be a manifest, which allows a bootstrap into different handlers)
... or should we go with an identifier per SRC system, but with a common payload

ian: then perhaps W3C could maintain list of "approved" SRC system URLs (as we do for network identifiers)
... are we on track to create this payment method, or what are we missing?

tomasz: We might be on track, though the timeline is aggressive
... one important point is to focus on the definition on the data model and to align as closely as possible to the SRC specification
... we should identify which use cases/flows we want to support, and then port from the EMVCo SRC spec into the payment method spec
... this would improve maintainability

ian: I strongly support that
... I would like the "W3C" spec to do as much as possible by reference to the SRC specfication

tomasz: the other challenge (input data in particular) is that some data are coming from the payment request API so some mapping will be required

jonathan: whose responsibility is it to create this stuff?

ian: In the wiki we try to identify the different pieces of the model
... there's the identifier, the data model and the algorithms
... obviously, EMVCo owns the data model. But who should write the text?
... we should try to get it to a certain point, and then hand over to EMVco (via Bastien) for review

jonathang: we should discuss in the Web Payment Security IG

ian: yes, we can let people know that the work is underway, e.g., once we have a draft. Bastien Latge already aware we are working on this.

jonathang: then we have to do discoverability etc

ian: then the question is - what should we be doing in this task force? Are there topics that we have not yet exposed?
... we should set a timeframe for our work

Ian invites comment from the other networks

<Ian> Jalpesh: let's write down use cases we plan to solve in first draft

<Ian> ...having MVP use cases for the first draft

ian: are there use cases listed in SRC-land that we can tick off?
... e.g. just within transactions?
... payment method specifications are agnostic to the payment handler (whether built-in the browser, native app, or web page)
... the same data model/identifier/algorithms are all the same for native handlers, web app handlers or browser
... the expectation is that users can say "this is my preferred handler"
... we have a list of UX assumptions
... but we don't yet have the conclusions
... but I don't think we have a conclusion around user ID

sophie: I am worried about the pace
... and I echo Jalpesh's thoughts about focussing on a MVP

jonathang: so we could go for the easy use case where we assume that there is a default handler (for example)

ian: who is going to dispatch to the correct handler?
... I don't know who is going to do that - should we assume that it'll happen, or not

<Ian> IJ: how much do we need to know ACTUALLY WHO IN THE WORLD will distribute a particular payment handler?

ian: so we need to hear from implementers of SRC handlers - we have not heard definitively from anyone that they are doing this
... I hear concerns about the timeline - what can we do before the F2F meeting?
... we need volunteers to do the work

<Ian> fawad: I echo others' comments

<Ian> ...aggressive timeline

<Ian> ...on the right track!

Ian: we have 5 calls between now and the F2F

<Ian> IJ: Recap of revised proposal

<Ian> - Work between now and FTF meeting on "how it will work"

<Ian> - Review with WG in Dubln

<Ian> - After that write the SRC payment method spec

<Ian> nicktr: I want to make sure we are going doing the right path.

<Ian> ...key to implementation will be payment handlers

<Ian> ...the strong ask from the chairs is -- if you want this method to exist and to work we need your help

<Ian> ..I'm fine with going with an MVP and making some assumptions (e.g., there's a default handler)

<Ian> ...but if we keep going around on what our assumptions are, we are not going to make progress.

<Ian> ...so we want to put a line in the sand and then start writing text; we need help doing that.

<Ian> ACTION: Ian to revise plan based on task force feedback

ian: we will revise the plan
... I have not yet heard volunteers for the document of how this will work
... Previously Tomasz had volunteered to document the flows
... any other volunteers?

<Ian> [IJ will re-ping Tomasz]

jalpesh: I will liaise with Jonathan on whether there is something we can re-use

Next call

<Ian> 22 January

ian: next call is 22nd January and we should aim to articulate the expectations of user ID

<Ian> ACTION: Jonathan to present at that call user identification problem space

AOB?

<Ian> IJ: FTF meeting opportunity to show of SRC in some form (merchant side or PH)