Web Payments Working Group

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