SPC Task Force

24 May 2021


Benjamin Tidor (Stripe), Chris Wood, Christian Aabye (Visa), Clinton Allen (American Express), Doug Fisher (Visa), Ian Jacobs (W3C), Jean-Carlo Emer (Stripe), Laura Townsend (MAG), Rolf Lindemann (Nok Nok Labs), Gerhard Oosthuizen (Entersekt), Rouslan Solomakhin (Google), Sameer Tare (Mastercard), Tomasz Blachowicz (Mastercard)
Praveena Subrahmany (Airbnb), Stephen McGruer (Google)

Meeting minutes

Scope + Requirements




Clearer benefits/features (pull request 70)


Gerhard: Will review today or tomorrow

Pull request 73



Gerhard: This is the "user gesture" bit, right

Tomasz: What about capability delegation?

Tomasz: I think this is a good requirement; capability delegation can help with the UX

Wrap up discussion raised by Tomasz and Stephen on GitHub:


Tomasz: How does API know that auth has taken place already?

rouslan: SPC requires a "key" as input.

Ian: But what impact would this have on the API?

rouslan: None

Tomasz: I am ok with requirement for in-transaction enrollment; but we may not need to mention "the user has been authenticated"

Action: Ian to revise the requirement to remove the pre-auth mention and to focus on the UX

Christian: In 3DS land, 3DS space would be where we talk about this.
… not sure it belongs in SPC

proposal regarding cardinality

Tomasz: I am hearing from API perspective that I provide an SPC Credential Identifier

Ian: The main proposed requirement is that "Each instrument is independently addressable."

<Gerhard> +1 for that unique addressability. Unique id for each instrument + auth combination.

Gerhard: I agree with the simple model
… but it does bring me to a use case comment: how do we handle scenario where multiple credentials are available

Benjamin: Regarding N > 1, the original expectation was "browser picks arbitrary one"

<Zakim> rouslan, you wanted to discuss cardinality and to talk about cardinality and failure experience

rouslan: In case of "no matches", the reqs returns error code without uX. That's the experiment we've been running. But there are some people who think that if there's no a user gesture requirement, there might be a way to iterate over a list of credentials ... and bad actors might use that info nefariously.
… so some people might be interested in an error message in case of no match
… regarding cardinality, I think that for each web site you'd have one credential
… some people want to reuse webauthn credential for payments
… the experience we've tested with SPC trial increases number of credentials

<Rolf> Note that it presents some level of friction to register an additional credential. So the ability to reuse one credential for auth and for payment is preferred from our side.

btidor: If we have a situation where N instruments can have signature from same key, we want to reduce avenues of attack, e.g., locking down cardinality as well as good practice to avoid vulnerability

<Gerhard> Thanks everone. Have to drop. Chat later

<jcemer> It is important to cover the case where the API is invoked with 2 credentialIds that are from 2 different instruments.

Next call

31 May

Summary of action items

  1. Ian to revise the requirement to remove the pre-auth mention and to focus on the UX
Minutes manually created (not a transcript), formatted by scribe.perl version 131 (Sat Apr 24 15:23:43 2021 UTC).