Started to talk about this but we quickly ran out of time.

Ian: Just to context set... web payments wg started in 2015 to streamline payments. The two main initiatives were to (1) reuse stored browser data -- enhanced autofill -- for 1-click payments and (2) connect digital wallets --payment apps-- to the web. The first did not catch on. The second has seen some implementation but has not taken over the web. But it has allowed for experimentation, of which SPC has been one.

While this was going on the payments community at w3c grew larger and stronger. In parallel we saw new ideas that bridge web payments and auth in order to satisfy use cases and some of the new EU compliance requirements ("PSD2"). Stipe did an experiment with impl in Chrome leveraging payment request API and payment handler API giving them the ability to interact with Banks (in a 1p context) as authenticator and handler - a first experiment using these capabilities as a pair.

In the future we expect to move away from payment request API. But I wanted to provide this background for why SPC is grounded in PR API.

One reason for urgency regarding the deployment of this API relates to the timing of EU requirements for strong customer authentication (SCA) for many transactions, as well as evidence that the user consented to the payment ("dynamic linking").

SPC involves user experience (modal window to confirm a transaction). There are two communications between the caller and the RP. The first is to get a list of SPC / FIDO credentials as input (along with challenge, amount, etc.). The second is to send the resulting assertion to the RP for validation. SPC is thus integrated into "back end" protocols, some of which may be standardized and others proprietary. Our current particular focus is integration into EMVCo's 3-D Secure, which is seen as an important tool by the ecosystem for fulfilling the EU regulations. But we are also having discussions about other integrations (e.g., EMVCo's Secure Remote Commerce and various Open Banking APIs in Europe).

This is how we got here with regulatory pressure and industry experience. A 2nd experiemnt between AirBnB and Adyen is happening and Stripe will be doing another one.

Tess: it's been a while since I looked at this. Lots of discussion taking place last month. Let's review these first.

(discussion about current comments)

Tess: Originally I had some minor issues around payment .... I am happy with the responce around the fact this is helping especially for existing form-based payments.

Ian: Here are use cases where I think SPC can be helpful:

• Form-based payments. That's what the first Stripe experiment showed.
• Card-on file payments. (Merchant or their payment service provider stores instrument information)
• Pay buttons (e.g., on click payment service fetches SPC / FIDO credentials from server using cookie-stored user identity; triggers SPC; sends assertion to server for validation; completes payment without ever requiring login).
• Digital wallets (who may want SPC above and beyond FIDO for the dynamic linking/transaction confirmation functionality)

Ian: All of these would involve a similar user experience. From arch perspective, SPC relaxes the WebAuthn same-orgin policy. Thus, any party may authenticate using the RP's credentials. We believe this does not create risks that payment will happen by mistake because in the end the RP needs to validate the assertion and will only allow payment if satisfied with the entire transaction context, including what SPC provides evidence for.

Ian: Second arch diff from WebAuthn is the ability to register in cross origin iframe. Chrome initially required a modal window in order to draw attention to the user. But they changed their mind and so the implementation currently does not involve a browser-owned notice during registration.

Ian: Let me back up a bit: the payments industry dislikes user friction. In this pursuit we want to have one fido registration used anywhere. Ideally with one registration you could authenticate from any browser, on any merchant web site, with that merchant using any PSP, and so on. There will be a variety of use cases, not all of which will achieve that ideal (e.g., where the PSP is the Relying Party rather than the issuing bank). Architecturally to get there, we'd like to leverage discoverable credentials, caBLE, and other Web Authentication aspirations. So we anticipate that SPC will stay close to WebAuthn to take advantage of these. In the meantime, the current API description includes some temporary "fixes" such as cacheing credential IDs. That is going to allow us to get some experience right away with SPC, but we anticipate over time that SPC will further converge with Web Authentication. In the long term, the main "non-WebAuthn" functionality will be the dedicated transaction confirmation dialog and the signing of transaction details.

Ken: So this should work with and without payment requests.

Ian: Yes. I think there is some agreement that SPC should not (moving forward) be closely tied to Payment Request. You should be able to use SPC on its own without PR API, in conjunction with PR API, and also from a payment handler. However, you can't use a payment handler today given SPC's implementation as a Payment Method.

Tess: This is a complex problem space with so much domain specific info, thank you for all the explanations Ian. It looks like it is in a good shape. When we design APIs in a vacouum we don't always see the rest of the industry or user cases. This one has a lot of thought and reason to get it to this point.

Ian: The 3PC removal will, I think, have a dramatic impact on payment ecosystem operations. We thought trust tokens might help but they can't since they're not really bound to anything. (explains a payment use pattern) So in summary, the payments world will need architectural help with identity, risk mitigation, authentication, and instrument selection.

Tess: So next steps are to create a new issue. Let's get this one reviewed and sign off on it as the current state seems very reasonable. Some of the open questions aren't necessary concerns to TAG and could be worked in the respective working groups, you're already doing this.

Ian: I think you should review in particular the security and privacy considerations. The Crhome team has been doing great work and helped us clarify a lot of considerations identified there.

Tess: Sounds good.