Meeting minutes
Improving Payment Request error codes in some failure modes
Dustin: show() aborts with an error in many different user journeys
Dustin: For our use case we expose events in two failure cases. But the spec does not give us a great way to do this.
Dustin: Generally what we are proposing is to distinguish two classes of errors; see the GitHub issue for a proposed solution
Dustin: Some concern is expressed since would be breaking.
… we are flexible about the mechanism used to facilitate this.
Slobodan: This resembles work we did in SPC.
Darwin: We have two error codes for different kinds of SPC cancellation.
Dustin: The most common error is a timeout. You can pass details to show (today it's an abort error)
… anything going wrong with fetching of service worker
… buyer cancels out of payment by closing the modal
The main question raised during the discussion was: Would there be privacy issues by providing more specific error codes? According to Dustin, they can already detect which error occurred based on the result strings provided by the implementation. The request here is to find a more durable approach through discrete error codes. The group agreed that we should seek privacy review of the proposed approach.
NickTR: Is there support from others for the feature?
… the GitHub thread suggests that entropy is not changing
… I hear two proposals from implementers.
IJ: Do others think that we should pursue this change in PR API?
<nicktr> I am supportive of this change. +1
<Gerhard> +1
<nicktr> +1 to add to the F2F agenda
Farewell to Rouslan
[Rouslan lets the group know that he has left Chrome Team to move into other areas.]
Rouslan: I've needed to move from Chrome to another project. I will be in the Google research team. I will miss you at TPAC!
Recurring payments and SPC
Tomasz: This is issue 185.
Tomasz: Recurring payments online (subscriptions, installments, etc.) are growing quickly, we'd like to add our support for this use case.
… this would allow us to increase the adoption of SPC
… the second objective is to leverage the cryptographic binding to include recurrence metadata .... this would give us better data to share with issuers.
… I think this is a relatively small and easy change
… I think it could be done either as an addition to the PR API or as an addition to SPC
… in the issue 185 description I provided in data elements of interest.
… metadata covers nature of payment, fixed or variable amount, and other metadata
Tomasz: We know that doing UX is challenging
Sharanya: What data would be given to issuer if customer is not present?
Tomasz: This proposal is not for the whole lifecycle of recurring payments, just to start the first transaction
… the first transaction is a customer present transaction; when they agree to terms, we will have evidence of consent.
Tomasz: This API will not report to consumer when a recurring payment has happened.
Sharanya: So this is for consent initially
Tomasz: I would not use the phrase "consent"; this is just to capture the information
… I would use "confirm"
… how this is handled by the PSP is a different story; this is just a technical facility
Gerhard: +1 for support of recurring payments
… I'm just looking at one issuer for 3DS. We are getting about 3-4% transactions as recurring.
… what is the motivation for you of the recurring payments use case over, say the "add card" use case?
Tomasz: I don't see use of SPC for add card
IJ: Who supports experimentation with recurring payments and SPC?
<Roger> +1
<nicktr> +1
<Gerhard> +1
Albert: The motivation for this...are you looking to bolster the merchant's rights in disputes?
Tomasz: Short answer is yes.
… and improve approval rates.
Support for multiple RPs in the Payment Request API for SPC
This is issue #310
Tomasz: There are use cases where it would be useful to be able to call SPC not just with a set of credentials from a single RP, but with credentials from multiple RPs. We might have, for example, passkeys from a card network, issuing bank, and PSP.
… what we want to do is bind them so that the user can pick one from the available list.
… we think that chances go up of authentication if multiple passkeys available from multiple RPs can be passed to SPC
Slobodan: What is your goal for the UX? Would you want / expect a chooser of credentials? Or is it more desirable for the browser to just pick one?
Tomasz: We want least friction; so don't ask user. We'd like to provide an ordered list.
… first match wins.
Ian: That's very helpful; please add that preference to the issue discussion. We will discuss this further face-to-face at TPAC (see the agenda). My guess is that we will discuss it on Monday (as part of the broad SPC discussion) but also on Tuesday (to the extent we conclude that there is an important dependency on WebAuthn).
Multiple scenarios to address regarding double step-up
Ian: We have two issues related to "double step-up" when an RP first encounters a BBK on a new device. The two step-ups are: (1) authenticate through SPC (2) because the BBK is not yet trusted, do a second step-up to ID & V the user. Tomasz, can you describe the difference between the original issue (287) and the new one (315)?
Tomasz: Because passkeys are synched, SPC can be called on multiple devices. Issue 287 addresses the case where a BBK is available on the second device, but is new. Issue 315 covers the case where SPC is called, but there is no BBK (e.g., because there is no secure hardware on the device so the browser has not created a BBK, or because the browser does not support the BBK feature at all).
… this is worse because there's no BBK ever, so I am double stepped up every time on that device.
… so scenarios covered by #315 are (1) unable to store BBK (2) BBK not supported in browser
Darwin: For the first issue (unable to store BBK) we were thinking of providing a signal whether BBKs are available, which would allow you to not have to go through BBKs.
Slobodan: In the "is spc available" API we could add "Is BBK available?
… another variant is to make BBKs a requirement of the spec
Tomasz: Yes, could add a signal for BBK available
Jean-Luc: Regarding BBK where there is no safe storage...if there is no secure storage, the authenticator won't have achieved a high enough FIDO certification level.
… so there might be step-ups if Level not known
… or accepted
… the bank might step up anyway
Ian: We will continue this discussion at TPAC as well. That is our next meeting.