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://
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://
issue 13
<Ian> https://
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