Meeting minutes
SPC design considerations
Ian: Please join into today's discussion. We welcome input from WG participants and guests to help us get started. Working Group participants will be doing the ongoing work; we'll say more about that at the end of the session.
Danyao: We've heard a lot this week about business benefits of SPC. The goals of today's session is to start to get to work on scope of SPC "Level 1"
… we'll look at design choices and options.
...the evolving consensus is that we are looking at Web Payments as three capabilities. We are focused in SPC on 2 of them: authentication and confirmation by the user of payment.
… the Stripe experiment was a baseline, but should not be thought of as SPC in its final form.
... What is SPC "REALLY"?
… payment authentication assertion (credit: Chris Wood)
… we want to introduce a new object that has some unique properties:
… proves possession and optionally a 2nd factor
… binds transaction details
… interoperable across all merchants and payment rails
<AdrianHB> +1 to "Payment Authentication Assertion"
Danyao: ...consistent and predictable UX
… privacy-preserving and strong security
… if consistent and predictable, will be reassuring to merchants and issuers
... We want this new object to act as a canonical proof for 3 questions: Is this the same device? same person? has user confirmed the transaction details?
Gerhard: This is pretty close. I think we've heard one other requirement - to indicate the mechanism of authentication.
Ian: Maybe it's "Authentication context"
<AdrianHB> ... was there an explicit gesture or not etc
Ian: I also heard "whether it was frictionless"...so there's a set of metadata about the auth experience
Gerhard: If we opt that can be done silently, then yes "how it was done" should be captured.
ChrisD: The "C" in SPC is quite key here. Yes, it's about secure authentication, but it's also key to capture the user's consent to make the payment.
… whether the consent is one-time, time bound, etc.
Danyao: Next step is to agree on a canonical user journey
… useful to have a shared mental model
… 5 steps:
- User creates a payment credential (during transaction or out of band)
- At another point in time, user initiates payment
- User challenged to generate a payment authorization assertion using the payment credential.
- Payer "bank" verifies the assertion and authorizes payment
- Some time later on another merchant, new payment authorization assertion using the same payment credential
Danyao: So if we have an assertion object and canonical user journey, here are some design questions for the "Payment authorization assertion":
- Who owns the credential?
- What is the data model?
- How is it created?
- How can it be exercised?
- How is it managed (i.e., lifecycle management)?
<Gerhard> Q: payment credential vs payment instrument? Do we have a preference?
<Zakim> ChrisD, you wanted to ask/suggest that confirmation is also included - i.e. consumer consents to their payment instrument being used
Danyao: In my slides I list some specific questions related to these five questions (the framework)
Gerhard: These questions apply to both the payment credential and the payment authorization assertion.
Danyao: Let's use terms "credential" and "assertion" for shorthand here.
James: +1 to Gerhard's point
ChristianA: The word "authorization" means something specific in the card world; heads up
Gerhard: How about "Payment Consent Assertion"
ChristianA: +1
<AdrianHB> +1
<btidor> +1 to Christian's point (not using "authorization")
Ian: +1 to "Payment Consent Assertion"
<Zakim> Ian, you wanted to raise question about design that may allow future work on instrument selection (just to register the idea)
<AdrianHB> ian: we are not addressing instrument selection but we may need the credential to have some identifier to support this in future
<AdrianHB> ... one proposal is to avoid identifiers in v1 but having said that the artwork and label do provide a visual identifier so we kind of have an identifier
<AdrianHB> ... we may want more in future
ChrisD: Maybe the name should be "Device Possession Assertion"? Or maybe it's "Instrument Possession Assertion"
Tomasz: Regarding name: +1 to not using "authorization" in the name of the assertion
… maybe it could just be "Payment Confirmation Assertion"
Jayaseelan (JC): Should there be a time-to-live in the assertion?
[Ian hears that as part of "lifecycle management"]
Ian: What is the subscription use case for these?
AdrianHB: I think we need to consider TTL for both the credential and the assertion. +1 to those design considerations
Tomasz: Revocation is another important topic.
Gerhard: On the TTL, we can reach out to the open banking standards for thoughts on the lifetime of consent.
<btidor> +1 to assertion expiry (maybe be configurable by issuer?) and revocation
Gerhard: ...in the oauth2 pattern I think there is a "1 minute" pattern; let's check that out
AdrianHB: Agree we need to accommodate policy options; but let's not dive into those today
Danyao: I want to briefly talk about how the design discussions map into API land.
... Key system objects from browser implementation perspectives:
- Assertion data model
- User experience
- Web APIs (e.g., for "creation" of credential by RP) and "exercise" by the merchant (or their PSP)
- Authenticator back-end. Could be client-side but could also be extended to payment apps. All of these backends might be able to cause assertion to happen.
- Network protocol - transit to systems like 3DS
<James> No need to discuss now, but seconding Ian's point above: Can you set up a subscription with an SPC? Then how would you amend, update, cancel.
SameerT: For assertion data model, look at what FIDO alliance has defined (e.g., as input to 3DS). Let's continue to look at how those data models connect
Gerhard: A payer bank will also want to exercise these credentials. A bank will want to get consent before doing a push payment.
ChristianA: We probably want both options: exercise on the merchant side (and in the background pre-AReq activities happen in 3DS). Or, "on the left side" there's a "CReq" model where there is direct interaction with the user's bank
Danyao: Design space in light of the above subsystems:
(1) Assertion data model
(2) UX: one click? zero click (no presence check)?
(3) Authenticator backend: FIDO, Payment Apps, "Possession Credential"
(4) Network protocol
(5) Web APIs
Danyao: Three different work streams moving forward:
1) Assertion data model
2) Use cases deep devices (lots of flows and UX and backend options)
Danyao: ...we are also likely to need to prioritize here and sequence them.
... After those discussions, we can start work on the API specification
... I'd like to hear who is interested in which flow (to help us prioritize)
Tomasz: Regarding the "Design Space"...I think of SPC as "network neutral"
… SPC should work with "all the networks"
... I like the fact that this is based on FIDO, but SPC should be usable in a variety of authentication flows
[Ian thinks there is still an open question from Entersekt on fallback to Web Crypto]
mweksler: Great presentation; I love the clarity on focus.
... From Airbnb perspective, very interested in exploring this further. We are very interested in the UX
...I want to focus on something that respects user preference AND has a really good UX.
… so an experience where the user consents is really interesting
... very interested in the checkbox "in the future on this merchant ok to not prompt me again"
... Would be interested in Airbnb being part of a pilot
AdrianHB: Based on what Gerhard presented, I think there's possibly a third UX dimension: authenticator assertion UX
Danyao: It's hard to fit all these cases into the boxes
… let's distinguish "button clicks" from "user gestures in the authenticator"
Ian: I am hearing three UX:
- Button click in the transaction confirmation dialog followed by authenticator gesture (multi-factor use case)
- Button click in the transaction confirmation dialog and no authenticator gesture (e.g., no user presence check because other two user gestures suffice)
- No button click at all (prior consent use case)
Ian: The implication is that the transaction confirmation dialog is frequently encountered, but not in the third case (no button or user gesture). That means that the transaction confirmation dialog itself is not the essence of SPC; it is the payment assertion.
AdrianHB: I think "Single click for both instrument selection and authentication" is also UX we should keep in mind
… so we should add a column for "instrument selection" since I think we can optimize there.
...so we might have "zero click auth" because instrument selection just happened.
Tomasz: I agree the UX is very important. I think there's another dimension whether we can quietly initiate the payment context, to allow the merchant to handle custom UI to get assertions.
<gkok> +1 on importance of fallback flow
Tomasz: We also want to discuss how to handle fail scenarios....how are fallback experiences provided gracefully?
Gavin: Regarding the UX...should we take into account "recent user gestures"
… for optimization?
AdrianHB: I think that one of the challenges we'll have is left to heuristics in the browser to protect user privacy v. specific user agent behavior
Gerhard: We are interested in piloting as well depending on where it goes
… might be useful to try it outside of Europe as well
… instead of "network protocol" maybe we want to refer to "pull" and "push" mechanisms.
[Ian is not convinced those are the only systems...we should also suppose proprietary payment mechanisms]
John_Bradley: FIDO authenticators can do checks with assertions (all the roaming ones at least)
… regarding scoping of credentials ... we scope them to RPID (origin)
… if you are issuing a credential across origins, are we scoping the credentials differently?
Danyao: I think we will scope them as FIDO does.
… but the API may allow other origins to "EXERCISE" the credential
… so the payment credential can be used as a FIDO credential for login by the RP, but can only be used for payment scenarios by other origins
AdrianHB: That's a feature with SPC as it has been experimented with today.
… the exercise can happen by another origin, but after 2 UX gestures in a payment context
John_Bradley: The merchant would need to know the RPID of the issuer
Danyao: For the pilot, the merchant did not need to know the pilot. The merchant does need to know the credential ID (and 3DS rails were used in the pilot)
John_Bradley: But the authenticator needs to know the RPID.
Danyao: The browser is taking care of that (in the pilot)
Aleksei: My compliments on the meeting and level of discussion.
… it's important to verify with a pilot
… Adyen would be interested in doing a pilot
Sebastian: Thanks for the presentation, Danyao. While we are talking about authentication...you mentioned platform authenticators for the pilot. Are you also looking at roaming?
Danyao: Yes, we've started to talk about it. As part of the work to make this a real spec we do need to figure out how roaming fits in.
Sebastian: Will PIN be supported?
Danyao: As long as people have a FIDO-compatible user-verifying authenticator, it will work by design.
Sebastian: Is there any provision that you share with the authenticator or will the authenticator be "self-contained"?
Danyao: The design is that the authenticator is self-contained. The browser will generate a hash that contains the transaction information and the original challenge. The authenticator does a regular signature of the challenge composed by the browser.
James: Thanks for the great presentation, Danyao. You talked about the "design space". Regarding the UX of "payment consent authentication". There's also design space around management credentials.
… e.g., the ability to update or cancel credentials.
AdrianHB: There will be an interesting line between "creation API" and "lifecycle management" as a distinguishing browser feature
<Christian> We have to define the data moved between the participants depending on who is reliant party - ultimately in PSD2 the payer bank is responsible to assert the authentication, so if they are not reliant party, they need data to prove that the "payment consent assertion" took place
AdrianHB: Can you say more about prioritization of use cases?
Danyao: I think I heard good signals. Great to hear from people that they want to do some pilots
Ian: Would be great to hear after SRC presentation tomorrow if payment app use case is still an important use case
[Discussion about payment apps initiating SPC]
[Next steps]
Danyao: We want to form an SPC task force that will meet regularly and come up with proposals for the WG
… the task force will also coordinate with other network backends (3DS, SRC, Open banking)
… the task force will then bring forward a draft spec (through the WG)
… on the slide we have some names of people who have expressed interest.
… we welcome others; please reach out to Ian
<AdrianHB> ian: we had a card payment security taskforce in the past that may still do SPC focused work for card payments
Danyao: Thanks everyone!
Worldline demo
Anne: While on their bank site, user has an opportunity to enroll cards for an SPC-like experience.
… during transaction, the user is redirected during checkout to the bank app
… the user selects the instrument, authenticates, and the payment is completed
Olivier: We see benefits of the payment app model.
… whether payment with card or bank account
… our use case is PSD2-compliant card payment.
… for us the key benefit of using the payment handler is that we can bypass the 3DS protocol but still keeping the 3DS fields that are required for the authorization request.
… we see the following benefits.
1) For the merchant it's simpler, quicker, more robust checkout.
… it is more robust because one avoids calls to the DS
2) For the card or wallet issuer, it provides an alternative to Web Authentication. Banks want a migration path.
3) For user, we think there will be greater trust in UX provided by issuer
4) This approach can be expanded by non-card payment scenarios.
… in short: Payment App + SPC can enhance the UX
olivier: Payment app provides direct channel to issuer, which has benefits
Jean-Michel: To explain our demo we have an animation of flows
gkok: For the onboarding process, what is exactly being stored in your demo? Is it the PAN or a network token?
Anne: What is stored is a payment instrument as defined by Payment Handler API
...what is stored is a "link" that the issuer associates with the user's instrument
... the credentials are stored in the browser but opaque to the browser; they are known to the issuer
Ian: Can you say more about "migration path" to WebAuthn?
Olivier: There are different security levels associated with WebAuthn. Some banks may want to implement this with a gradual approach ... and may not want WebAuthn depending on the user device
Jean-Luc: If I understood ,there is no DS and the bank authenticates the user. For 3DS the DS also validates the merchant to a certain extent.
… in your demo, there is no way for the merchant to prove that there was an authentication.
Anne: There is also no way to get the PAN if the bank is not reachable.
... If the bank is unreachable, there's no payment.
Olivier: Similarly, if SRC system not available you don't get a token/PAN
Jean-Michel: Our goal in the demo was to remove the DS. But of course if bank is not reachable, there is no payment.
Olivier: The schemes could be the ones who provide the payment handler (or part of it, on behalf of the bank)
Anne: The issuer / ACS is the same domain. We assume here that the issuer is able to rely on the ACS to provide fields.
Christian: I am hearing that the issuer emulates an ACS (either by working with an ACS or getting the data otherwise)
Olivier: This function can be performed by ACS, issuer, or Schemes.
… in our demo, we don't need the DS to find the card issuer
… when you enroll via a payment handler, you have a direct link to the issuer
...in short, we are simplifying now that there is browser functionality (Payment handler API) that was not available 20 years ago.
SameerT: I think part of my question is how 3DS fields are generated without 3DS services being involved.
<Zakim> ChrisD, you wanted to ask what will happen if the user hasn't enrolled prior to making a payment? Don't you need the Directory Service to support 'in payment' enrollment as an option; otherwise how do you find the right issuer to enroll with?
ChrisD: Without the DS you can really support "in-payment enrollment" flows...unless the payment handler has a BIN lookup capability.
Jean-Michel: Agree with that comment, but the purpose of the demo was to show the role a payment handler can play to simplify.
… you can still do "3DS things in your payments" without the DS
ChrisD: I can also see advantages in latency and reliability
… but one cost is that you may need to support two flows: pre-enrolled v. during-transaction
Jean-Michel: Agreed
PROPOSED: The WPWG should take up SPC as a formal work item.
<AdrianHB> +1
<benoit_> +1
<Gerhard> +1
<btidor> +1
<Vaishali_Bulusu> +1
<frank> +1
<mknowles> +1
<Fawad> +1
<Aleksei> +1
<Anne> +1
<danyao> +1
<James> +1 (non member, but support!)
<Christian> +1
<SameerT> +1 non member support
Chrome Origin Trial
Danyao: Chrome has started a second origin trial for SPC as of Chrome 91. Quoting: "Secure payment confirmation augments the payment authentication experience on the web with the help of WebAuthn. The feature adds a new PaymentCredential credential type to the Credential Management spec, which allows a relying party such as a bank to create a PublicKeyCredential that can be queried by any merchant origin as part of an online checkout via the Payment Request API using the proposed secure-payment-confirmation payment method."
Danyao: We are balancing with the ability to experiment; origin trials let us try out new APIs without saying "this is final"
... traditionally new features were hidden behind flags. Origin trials let people enable features on the experimenter origin, and the user doesn't have to flip any settings. See the origin trial instructions.
AdrianHB: If people want to enable their origin, what what part of the flow involves origin checks
Danyao: Two extensions are (1) payment credential creation (2) exercise via PR API
… the origin that hosts the JS needs to opt in to the origin trial
... Origin trials have expiration dates. SPC2 through Chrome 93. We can extend, but this is meant to prevent reliance. The SPC task force will develop the "real" API for future reliance
Today's Wrap-Up
Upcoming meetings after tomorrow's last day:
15 April: I18N issues
29 April: New ideas on hasEnrolledInstrument
AdrianHB: Thanks Danyao! Excited to start this work
… thanks Anne and Worldline for the demo and discussion
… the demo speaks a lot to how I have thought of the browser as playing a role in interop.
… demos are always welcome to spark conversation and visual what we are doing
<Deepu> Thank you everyone