Web Payments Working Group

27 May 2021


Anne Pouillard (Worldline), Chris Dee (FIS - Worldpay), Chris Wood, Clinton Allen (American Express), David Benoit, Davor Davidovikj (Adyen), Erhard Brand (Entersekt), Eric Alvarez (Adyen), Fawad Nisar (Discover), Gavin Shenker (Visa), Gerhard Oosthuizen (Entersekt), Gustavo Kok (Netflix), Ian Jacobs (W3C), Jean-Michel Girard (Worldline), Jeff Hodges (Google), Lauren Jones (Huawei), Nick Telford-Reed, Pierre Walden (FIME), Stephen McGruer (Google), Vincent Kuntz (ISO 20022 RA)
Jean-Luc Di-Manno
Nick, Ian

Meeting minutes

Use cases / scope

ian: SPC taskforce has been making good progress
… we meet on Mondays
… we have a timeline which tries to get us to a FPWD by this summer
… and shipping code in Autumn

<Ian> Scope and use cases

ian: today we'd like to give you an update on scope

[Ian presents]

ian: we have a draft definition
… I merged a pull request today on features and benefits
… "here's what you get with SPC"

1. Authentication streamlined for payments

2. Scalable and Ubiquitious

3. Designed to meet regulatory req'ts

4. Simpler and more secure front-end development

ian: unique features

1. Browser-native UX for payment confirmation

2. Cryptographic evidence

3. Cross-origin authentication

ian: We have also been documenting user stories
… which we have not yet prioritised

ian: I invite everyone to read the user stories and to let us know if you have questions or to document missing use cases

<Ian> Nick: I urge you to have a look and send comments.

<Ian> Requirements

issue 65

<Ian> https://github.com/w3c/secure-payment-confirmation/issues/65

ian: do you need payment request for SPC, or are they separate?

smcgruer_[EST]: It's really important that we don't get tripped up by terminology
… inside a payment handler == inside payment request for me

ian: I had imagined you could use paymentrequest constructor and then call SPC
… or while a payment handler is running
… or (outside) you just call SPC
… there's no payment request
… in this third situation, there's no payment method - it's just calling for authentication

<Ian> Three scenarios:

<Ian> 1) In PR API on merchant site

smcgruer_[EST]: I think we have concrete users of scenario 3

<Ian> 2) In PR API in payment handler

<Ian> 3) Unrelated to PR API at all (e.g., Stripe experiment)

smcgruer_[EST]: we don't know of of payment handlers that want to use it
… and I don't understand scenario 1

ian: it could be a method within payment request _OR_
… it could be a new API (called SPC)
… I feel like it's foundational

smcgruer_[EST]: Do you want to get into the JS shape?

ian: I do want to know if you have to trigger payment request or not

smcgruer_[EST]: I am ambivalent to this issue
… I do think it should be callable by both merchants and within a payment handler

Gerhard: I think I should be about paying a merchant

<Ian> Gerhard: I need to be able to trigger SPC from an issuer domain. See usefulness of being able to trigger from merchant domain

Gerhard: I want to be able to kick it off from a merchant domain, an issuer domain _or_ a scheme domain
… I think Tomasz asked if you could just do "credential.create" rather than "paymentrequest.authenticate"
… I do think should be bound to a payment

smcgruer_[EST]: you mentioned that the credential should only used for payments
… we have heard that others would like to be able to use for other uses

Gerhard: I think we devalue the transaction if we don't bind to payments

ian: could we re-use a credential for other things? Yes
… but SPC should be payments

<smcgruer_[EST]> +1, I misunderstood :D

gerhard: I think the credential + payment instrument is critical
… I think secure display is critical
… I think frictionless is a different construct

ian: would you write up the non-fido use case?

Gerhard: I think we have done that
… including the explainer

ian: I will open an issue

ian: I am not hearing strong views on SPC invokable independent of payment request

ChrisD: I agree with Gerard that SPC should not ‘embed’ FIDO. Other authentication mechanisms are available.

ian: in the requirements doc, we say you should be able to call SPC from a payment handler or a website

<Gerhard> Non-fido challenge defined at https://github.com/entersekt/possession-credential with presentation at http://www.w3.org/2021/Talks/entersekt-20210330.pdf

issue 13

<Ian> https://github.com/w3c/secure-payment-confirmation/issues/13

ian: one credential per payment instrument? Or one credential for many payment instruments (e.g. while logged into you online banking)? Or many credentials for one instrument (different browsers)

ian: the key requirement is everything is independently addressable
… we don't want to constrain implementations

ian: this is what we documented in the requirements

smcgruer_[EST]: I don't understand the constraint

ian: The intention is for the credential to be at an instrument (like a card number) level

benoit: the binding of a card has been static traditionally but firms like Curve have made that fluid

ian: I don't think the text needs to change

<Ian> nicktr: I want to point out that it's turtles all the way down here.

<Ian> ...you are talking about about "instrument" v "account"; funding PAN can be represented by a universe of token pans

<Ian> ...not sure definition of "instrument" is adequate

smcgruer_[EST]: I strongly believe that the meaning of credential is up to the relying partner
… I don't think that the SPC spec should force that binding
… today the only reason we have the binding in the explainer is because we store somethings in the browser _in our first implementation_
… I think that should be up the RP

<Ian> smcgruer_[EST]: You could move binding to auth time (rather than static binding)

<Ian> Gerhard: SPC should not require a selection to be made

gerhard: I think that SPC should represent where the money is coming from
… in other words, a credential == "where the money is coming from" without further user selection

gerhard: I am strongly in favour of 1:1
… this creates sureness for consumers

<Ian> Chris: For SPC to work with open banking, needs to be account (source of funds)

Chris_Wood: in an open banking context, instrument == "bank account"

<Ian> ach mee

Chris_Wood: it's "where do the funds come from" afaic

<Zakim> Ian, you wanted to mention "2 user account" use case and to ask about regulatory requirement

<Gerhard> +1 to that

ian: I think the dynamic linking regulatory element is important
… do we know what the specific requirement is wrt to funding source?

<Ian> Ian: Question is "dynamic before sig" or "dynamic after sig"

smcgruer_[EST]: I think the binding is at "auth" time

<Ian> smcgruer_[EST]: I want strong binding at auth time, not enrollment time.

smcgruer_[EST]: not at registration time

gerhard: if have multiple authenticators, how does that work?
… can someone take me through that?

smcgruer_[EST]: you will always have a separate credential per authenticator
… but let's imagine you have a visa card and a mastercard from the same issuer
… for a particular payment, I select the mastercard
… the merchant sends that through
… the RP (issuer) sends the authenticator credentials for that instrument
… but also (possibly) here are the other instruments
… by sending the info at authentication time

ian: I am hearing a strong push for the binding no later than authentication but not necessarily at enrolment time

ian: We need to revisit the requirements
… I believe that there is consensus that what you sign is what you're paying with

nicktr: You asked about regulatory requirement re: dynamic linking.
… I don't think it binds the instrument; it binds USER, amount, and beneficiary

Action: smcgruer_[EST] with rouslan and Ian to work on refining requirements to support authentication-time binding to concrete funding source

ian: Rouslan and Ian will work on that while smcgruer_[EST] is enjoying well earned vacation

ian: I suggest we revisit the next two agenda items next time

Next meeting

<Ian> 10 June

Summary of action items

  1. smcgruer_[EST] with rouslan and Ian to work on refining requirements to support authentication-time binding to concrete funding source
Minutes manually created (not a transcript), formatted by scribe.perl version 136 (Thu May 27 13:50:24 2021 UTC).