Should SPC be invokable outside of a PaymentRequest flow?

[stephenmcgruer]

Ian and I were chatting today and discovered that we had very different mental models about when SPC authentication is invokable; it seems worthwhile to hash these out and come to a conclusion that we can document (as part of the Scope document?).

Some casual definitions:

• A payment context: a state in which the user views themself as in the process of a financial transaction (often referred to as being in a 'payment flow'). Divided into:
  • An informal payment context: a payment context in which the flow is not visible to the browser (e.g. a checkout flow implemented with generic web APIs).
  • A web-api payment context: a payment context in which the flow is happening via payment-related web APIs (e.g. inside of PaymentRequest.show(), such as a web-based PaymentHandler) and as such is visible to the browser.

Given these definitions, I believe that SPC authentication should be invokable in both informal and web-api payment contexts. Do others agree?

Note that if SPC is invokable in informal payment contexts, it is invokable anywhere on the web as the browser cannot tell the difference. It should always require a user gesture, imo, and the browser UX that will be shown should always state a payment context.

[stephenmcgruer]

For completeness: SPC as described in the explainer is only usable in an informal payment context, not a web-api context. Although explainer-SPC uses the PaymentRequest API, it is not part of a PaymentRequest flow; it's just piggy-backing on the existing infrastructure. The explainer version of SPC can't be used inside a PaymentRequest flow (e.g. a web PaymentHandler), because PaymentRequests cannot be nested (step 8 of show() - https://w3c.github.io/payment-request/#show-method).

[cyberphone]

@stephenmcgruer Since you requested input on a pretty fundamental issue, may I as an external comment on this?

IMO, SPC is (or should at least be), a browser-built-in payment-handler, activated by the existing PaymentRequest API for usage in payment scenarios. Personally, I would limit the scope even further by making crypto = FIDO. Going outside of this already quite challenging scope would IMO be unwise (unless it is supported by peer-reviewed, fairly complete specifications, and thoroughly tested code).

Other solutions and scenarios can presumably be supported by existing Web technologies.

In case you want to discuss this further, please use my email: anders.rundgren.net@gmail.com.

@rsolomakhin @nickburris @btidor-stripe @jcjones

[SensibleWood]

+1 on @cyberphone comments. Anything that is 1) not tied to the Payment Request API and 2) not FIDO has the net effect of making of the scope explode IMHO. The neat thing about the original SPC proposal was the the use case was clear, unequivocal and single-minded in its purpose. FIDO2 + Payment Request API === a chance of success and adoption.

[cyberphone]

A closely related issue...
If SPC becomes a "security framework" that only kicks in when required (like 3DS), it won't become a brand. This departs from essentially every other system out there, from PayPal to SRC:
https://www.emvco.com/emv_insights_post/introducing-the-click-to-pay-icon/

This is how I envision SPC could appear on a merchant checkout page, here supporting three different payment networks:

For Open Banking implementations, the name of the payment network would probably be something like "Pay with your Bank" .

[adrianhopebailie]

SPC is not an "API" it is a function.

It should only be available inside the formal PR API call for the reasons specified in #56 (comment)

I wouldn't read much into the API shape as defined in the explainer. @danyao and I agreed early on that the design for the experiments was simply a "quick and dirty" to get some data.

My mental model for PR API is that it is simply the way a website invokes a payment context. We have already made some big simplifying changes to PR API through w3c/payment-request#955 to make it more flexible. I don't believe there is a concept of a "Payment Request flow" since the browser is no longer collecting data on behalf of the website.

I imagine functions available inside the payment context being:

• User identification
• Instrument selection
• Authentication and payment confirmation (SPC)

The specific functions available and invoked inside the payment context will differ depending on how the PR was constructed. E.g.

1. If a website already knows which payment credential will be used to authenticate the payment it might call PR API and pass the credential with the request but not specify a list of payment methods (similar to the API design in the explainer)
2. If a website has a list of payment credentials that could be used it could call PR API and pass all of them to PR API and the browser will prompt the user to choose a payment instrument linked to one of them (assuming more than 1 has been enrolled previously).
3. If a website has a list of payment methods it accepts and is unsure if any payment credentials are already enrolled it can specify the list of payment methods and the browser will prompt the user to select a payment instrument matching one of the payment methods.
4. Etc.

I think we should not get too far ahead in trying to design the API shape for SPC (or start assuming it won't be part of PR API) until we have ironed out the scope and requirements a little more.

@cyberphone SPC is NOT intended to be a brand. It is an authentication and confirmation framework that can be leveraged by existing payment methods. The goal is to standardise the primitives for authN and confirmation so that this is possible.

[stephenmcgruer]

Thanks @adrianhopebailie

I believe you and I agree, and are just using slightly different meanings for terminology. Everything in your post I agree with except the 'theory' parts (what constitutes a payment context :D).

I have trouble explaining things here without relying on some concrete proposal, to be honest. The core of this issue was that I don't want merchants to have to switch to Payments-related web-APIs for anything other than SPC, to use SPC.

That is, if a merchant, Alice, has a HTML-based guest checkout form setup that's working for her today (so no Payments web-APIs there), she should be able to integrate SPC to get strong user authentication without needing to adopt any other Payment APIs (such as, if you'll excuse the concrete example, the use of a PaymentHandler like basic-card, Apple Pay, or Google Pay).

[cyberphone]

@adrianhopebailie writes

SPC is NOT intended to be a brand. It is an authentication and confirmation framework that can be leveraged by existing payment methods.

This excludes a wallet which @stephenmcgruer has in private communication mentioned as likely to be a part of SPC. Does the world really need yet another framework? Wouldn't a concrete system be easier to define, deploy, and market?

A framework will be facing a virtual army of quite popular and useful mobile payment and banking applications. A Standardized, Vendor-independent, Convenient, Secure, Universal, and [potentially] Always Available alternative is (standards-wise) probably the only thing that could make a real impact in a market which currently have to cope with an ever-increasing number of "innovative" payment solutions.

[ianbjacobs]

Hi all,
We discussed this at our 27 May teleconference:
https://www.w3.org/2021/05/27-wpwg-minutes#t03

(No strong feelings were expressed there.)

[adrianhopebailie]

@stephenmcgruer I think we are on the same page but perhaps have different ideas about HOW someone could use PR API, for example if all they want is SPC.

You said (and I agree with this):

if a merchant, Alice, has a HTML-based guest checkout form setup that's working for her today (so no Payments web-APIs there), she should be able to integrate SPC to get strong user authentication without needing to adopt any other Payment APIs (such as, if you'll excuse the concrete example, the use of a PaymentHandler like basic-card, Apple Pay, or Google Pay).

My expectation is that in this case Alice would create a new PR object but would not specify any payment methods (i.e. telling the browser she is not interested in invoking browser facilitated instrument selection or any third-party apps). She WOULD set a flag, or provide some input data (such as a list of credential IDs) that indicates she wishes to do SPC if it is available.

This creates a clean DX where any functions related to payment are part of PR API.

[adrianhopebailie]

To elaborate a little on the DX and UX I have in mind here.

When a merchant invokes a new payment flow they may have very little data already about who the user is and how they wish to pay (e.g. guest checkout) or they may have a lot of this data already (instruments, user id, credential ids etc).

They should invoke the PR API, providing the data they do have and indicating to the browser (via the options argument) which browser-facilitated steps in the flow they wish to enable.

The flow, at a high level, works as follows, where the browser MAY facilitate any or none of the steps:

1. Identify the payment instrument to use
2. Authenticate the user
3. Confirm the payment details
4. Authorise the payment

The flow is a 3-party flow involving the merchant, the RP, and the user with the browser as the mediator between them.

The flow is invoked by the merchant calling PR API show() and control is passed to the other parties by the browser as appropriate based on:

1. The data provided by the merchant
2. The available payment handlers installed
3. The available payment instruments installed with associated SPC credentials

Control is passed to the merchant via events on the PR object, to the RP via events in the RP's payment handler and to the user via UI rendered by the browser.

My expectation is that there will be 3 ways to invoke SPC:

1. By the merchant by passing the required data directly into PR constructor
2. By the merchant inside an "instrumentSelected" event emitted by the PR object
3. By the RP (via an API exposed inside a payment handler, or via PR API from inside an iframe the same as the merchant methods above)

Example of 1:

  let details = {
    total: {label: 'Total', amount: {currency: 'USD', value: '55.00'}},
    secureConfirmation: {
        credentialIds,
        networkData
  };
  let options = {requestSecurePaymentConfirmation: true};
  // Empty paymentMethods means skip instrument or payment handler selection
  // Using PR constructor still gives us the structured payment details to use in confirmation
  let request = new PaymentRequest([], details, options); 

Example of 2:

let request = new PaymentRequest(methods, details, options); 

// Merchant binds to instrument selection event so browser doesn't attempt to invoke payment handlers
// Instead user will be prompted to select a payment instrument from installed instruments filtered by supported payment methods
request.addEventListener('instrumentselected', async function(evt) {
    const networkData = await getChallenge() 
    // Do SPC using the selected instrument and the challenge from the RP
    const response = await evt.confirmPayment(networkData)
    await response.complete('success')
});

Obviously this is very speculative but it provides some illustration of the direction I was imagining. Does it make sense?

[rsolomakhin]

HI @adrianhopebailie,

I would prefer to keep the API as simple as possible for a number of reasons. One of the things that I'd like to avoid is instrument selection in the browser UI, at least for now. That means the instrumentselected event may not be a good fit.

Distinguishing between the merchant and the RP and communicating with them in different ways also appears to introduce extra complexity without a well defined benefit. Can the API communicate only to the current web page?

As for "Example 1", it seems counterintuitive to pass in 0 supported methods, but then add requestSecurePaymentConfirmation as an option.

What do you think about an API shape like this:

new PaymentRequest(
    [{
      supportedMethods: "secure-payment-confirmation",
      data: {credentialIds, challenge, timeout},
    }],
    details);

Cheers,
Rouslan

[ianbjacobs]

@rsolomakhin,

If SPC can be called outside of PR API, then I suggest that we not follow the pattern of your example. SPC is not a payment method. It is an authentication approach. It is not a peer of GooglePay, ApplePay, SamsungPay, SRC, etc. It should be usable by them during PR API or by a payment app. It should also be usable for vanilla form-based payment flows.

[rsolomakhin]

It should be usable by them during PR API or by a payment app

Could you provide more detail on how that would be accomplished?

It should also be usable for vanilla form-based payment flows.

That's what new PaymentRequest([{supportedMethods: "secure-payment-confirmation"... accomplishes, right?

[ianbjacobs]

That's what new PaymentRequest([{supportedMethods: "secure-payment-confirmation"... accomplishes, right?

Yes, except this isn't a payment request. In my mind:

• Payment Request means "Get me some payment credentials."
• SPC means "Get me some authentication credentials."

So I would not call "new PaymentRequest()" but "new SecurePaymentConfirmation()"