Meeting minutes
Welcome, logistics
Adrian: Thanks for joining (especially for people up late or early)
… we miss in-person; thanks for coming
… most of the focus this week will be on SPC
Background to the agenda
<AdrianHB_> [Ian talking through slides]
AdrianHB: I started a new job in August and so my plan is to step down as co-Chair.
… the timing is opportune since we are rechartering
… Nick, Ian, and I are still working on the timing
… if you have suggestions for co-Chairs, please reach out to Ian and Nick
… thanks to Ian who makes this job easy
… it's been very fulfilling to work with all of you
… optimistic about the work we've done.
PROPOSED: To thank Adrian vigorously for his service
<rouslan> +1000
<benoit> +1000
<Ian> +1000
<ChrisD> +1000
<jeff> +1000
<Gerhard_> +1000
<nick_s> +1000%1
<Manish> +1000
<manu> +1000 :)
<aleksei> +10000
AdrianHB: I'll remain part of the Working Group in some capacity
SPC status in Chrome
Stephen: Let's review SPC over the past year. Goal: Simple, seamless, and secure user authentication for payments
… but I would add since 1 year ago explicitly "in a privacy preserving way"
… SPC helps to address some pain points not directly addressed by Web Authentication
… this has led to the SPC superpowers (different from Web Authentication capabilities):
- Credential creation in a cross-origin context.
- Parties other than RP can initiate authentication ceremony.
- Browser UX to display transaction confirmation, with signature by authenticator of displayed data (for dynamic linking and similar regulatory requirements)
[Stephen walks through some SPC design history]
Stephen: SPC in Chrome 95 on some platforms as of last week.
Stephen: What does SPC look like today? WebAuthn credential with "payment" extension.
Stephen: Because this is a WebAuthn credential, it can be used for login use cases as well
[Stephen on addressing timing attacks with UX]
Stephen: On the future of SPC:
… we think it is in a good v1 condition.
… we'd like to see a lot more adoption this year.
… we also see a v2, with changes based on industry adoption
… things that interest us in particular:
a) Solve the cross-browser problem. Would like users to be able to use any browser on the device where registration happened.
… hope to fix with tighter integration with WebAuthn
b) Would like to include Android support and that's not far off (but we need support for discoverable credentials first)
c) Would like more ergonomic API shape (easier feature detection). See issue 65.
d) More privacy considerations.
e) More! Dark mode support, other Ones
Weiler: You said that SPC credentials can be used for login.
… is there a use case for creating login credentials for SPC?
Stephen: Yes.
… the RP would make the decision.
Weiler: But would that allow other sites that are not doing payments to work around origin barriers?
rolf: How can you get around the barriers? The user will be presented with a payments-specific user experience.
Weiler: Imagine you have a set of RPs that want to break the barrier.
rouslan: We think that (in the future) all of WebAuthn will have the ability to create credentials in a cross-origin fashion.
… but the only way for a 3rd party to query the credential is through payment specific UX
Weiler: There might be social engineering to try to fool the user.
Rolf: I don't understand how the RP would know the public key
Weiler: I'm imagining a case where RPs want to break down the barriers between origins
Rolf: The RP that is tied to the credential would need to publish the public key
AdrianHB: There's always a user interaction
Weiler: I am concern bad RPs will try to train users to respond to that UX in order to get around limitations
Alain: Changing topics a moment: I had not realized you needed to do register explicitly for SPC (as opposed to just leveraging vanilla WebAuthn credentials).
Stephen: The WebAuthn raised a concern. We had wondered whether vanilla WebAuthn should "Just work"
… but the WebAuthn folks imagined login attacks (malicious attacker, innocent RP)
… the RP might accidentally not verify credentials correctly (that is: they might accept payment credentials as login credentials by mistake).
… there was also a user experience concern...
… SPC allows a dialog to appear with another origin's name on it
Alain: A down side is that the user will tend to only register with a few merchants.
Stephen: Going forward, if you register with your bank for SPC, then you can reuse that across transactions.
Ian: Alain, you raise a good point about scalability. I have written a blog post on this topic: various design and implementation choices that enable scale. So it will be possible to do lots of authentications across merchants for a single enrollment, whether the RP is the issuer or the PSP or some other party.
<Zakim> AdrianHB_, you wanted to ask if the plan is still to move to credentials.get instead of PR.show?
AdrianHB: We discussed API shape on GitHub some time ago (issue 65). Is the plan to still move away from PR API and closer to some other API?
Rouslan: I think the plan is to take a look at the API shape and decide if navigator.get is preferable
… I'm pretty sure it would be better. But we may need to make adjustments like requiring user gestures.
Stephen: There's no concrete plan at this time, but we do think some change should happen to make the API more ergonomic
AdrianHB: But roughly the goal is for SPC to work with vanilla WebAuthn credentials without a need for an extension
… but some features need to be available to support this like discoverable credentials.
Stephen: So far the WebAuthn WG is pretty set that a vanilla WebAuthn SHOULD NOT have the ability to perform a cross origin ceremony
weiler: What about the prohibition on roaming authenticators?
Stephen: We would like to take advantage of roaming authenticators, but have not figured out how to do so
… some ideas like "Plug in your authenticator if you have one"
weiler: I see there is a milestone for roaming authenticators that says "complete"; where does the WG want to track roaming auth support?
[Sam reopens issue 12]
<nick_s> Thank you everyone, I have to drop out but I will see you all for our next session tomorrow. Very interesting work on SPC.
Gerhard: Thanks for the walk-through. If the current implementation means you cannot dynamically make a WebAuthn credential an SPC credential, I think we will almost always create credentials with the payment bit set.
… is that a desirable outcome?
… I would like to decouple capabilities (1) cross-browser availability and (2) using a WebAuthn for payment confirmation
… what does it mean if RPs always set the payments flag just to be sure?
... Are we prepared to say "best practice" is to set the bit?
… I think it will become the norm
weiler: Just to note, my concern earlier was about payment credentials not being used for payments. Perhaps there's a way to provide a switch so that the user can turn on/off whether a credential can be used for a payment.
Gerhard: +1 to a tick box to "untick" a payment capability
Rolf: I'm still trying to understand the risk associated with Sam's use case. Federation is available today to enable parties to share a credential.
...Cross-origin iframe WebAuthn authentication also works today.
... With SPC, the browser renders the dialog; the assertion goes back to the PSP who sends it to the RP for validation.
… if the PSP and RP collude, then it will still be confusing to the user to see a payment dialog (instead of the typical terms and conditions screen)
… so I don't see how the Payment UX can be practically used abusively
David: Regarding "merchant of record" style purchases.
... Sometimes merchants are working with providers specifically to facilitate payments. If the PSP is the merchant of record, how can I set that up?
Rouslan: There are 4 origins in the signature:
- Address of the page (URL bar). This is displayed to the user.
- Payee Origin. This is displayed to the user
- If SPC called from iframe, origin of iframe.
- Origin of relying party.
Rouslan: The API creates a signature over all four of them. The RP can do whatever they want with that information.
benoit: I would love to see more on intelligence we can do on that data
Rouslan: Regarding 'issuer side intelligence', if your issuer is the RP, they are enrolling the user and they will be able to collect all the data and verify it.
… if you delegate, then that party can do it, etc.
… there are server-side libraries to do validation
… if you pass a WebAuthn signature to the Java library webauthn4j and a public key, it will return a boolean
… if you pass an SPC signature to the library it will BREAK
… but that's intentional. We don't want RPs to unknowingly accept payment signatures for login
… but there's a branch of the webauthn4j library with a separate method for verifying a payment-related (SPC) signature
… and there are more things you can check for (e.g., instrument display, merchant, amount, etc)
Jordan: Does SPC support instrument selection logic? That is, does SPC allow a merchant to specify currencies they accept, and have the user shown only the subset of instruments that provide those?
Ian: Short answer is no. The Web Payments architecture at a high level consists of these parts: (1) user recognition (2) instrument display and selection (3) authentication. Payment Request API addresses instrument display and selection and the user agent does some filtering as you describe. But SPC is dedicated to the authentication step. We will be talking about user recognition on this week's agenda.
Rouslan: SPC does not evaluate the currency provided as input to the PR API call for SPC
… the browser just displays it in the dialog
… the currency code is part of the signature to tell the RP that the user agreed to what was displayed
SPC issue review
SPC Issues selected for review during this meeting.
Issue 93
Stephen: Issue here is where information (e.g, text on instrument string) is internationalized (direction, language). Important for rendering, screen readers, etc.
… there's a proposal on the thread.
… but Localizable does not yet exist
Ian: We'll discuss with I18N folks this week
Issue 101
Stephen: This works today (we support data URLs) but there was an issue about including data URLs in JSON clientData
… and that might be a lot of data for authenticators with limited storage
… we now have at least 2 implementers who have things up and running and there are not any complaints
AdrianHB: If you include a regular URL you have no idea what was fetched
Ian: I reached out to some PSP and card folks to find out if it was important to have a record of exactly which image bits were rendered. I heard "no that's not important".
AdrianHB: Then it becomes a risk decision topic
rouslan: The data URL solution solves the "exact bits" approach when needed
AdrianHB: So the RP can make local policies
Ian: Let's provide some informative note in the spec to say "use data URLs if you want a record of the bits shown"
AdrianHB: +1
<smcgruer_[EST]> SGTM, ship it
Action: For issue 101, Stephen to write a pull request for a note about data URL v HTTP(S) URL
<AdrianHB_> +1 to close the issue too
IJ: So what is signed?
AdrianHB: The URL
… also, they hash data before it's sent to the authenticator so storage limits not really an issue
PROPOSAL: Specification today satisfies issue 101. Add a note on usage of data URLs.
<rouslan> +1
<Anne> +1
<ChrisD> +1
<AdrianHB_> +1
<aleksei> +1
<smcgruer_[EST]> +1
SO RESOLVED:
Action: Ian to close issue 101 with note to minutes
<Ninika_> +1
Issue 125
Should SPC allow for a failed download of the payment instrument icon?
Stephen: This originally came up as a bug in chrome.
… but partner indicated they'd rather have something other than a fatal error.
<benoit> alt text in this case? text that would also be signed as part of the request?
Stephen: my proposal at this point is to close the issue and leave it as fatal; that is no built-in recovery mechanism.
… Erhard proposed to catch first failure and retry
… but Rouslan pointed out that another user activation would be necessary
… but we're not hearing demand so I propose to close issue 125 with no recovery mechanism.
...Today the promise is rejected with a general issue. We can (and should) have a more specific error message about why the failure occurred.
AdrianHB: What was the idea of the recovery mechanism? That there was something in the signature to indicate something failed?
Stephen: We'd sign empty URL or a bit that said we have not displayed it. The proposal was to do UX with a blank icon
AdrianHB: We could also add an explicit bit in the signature "Image was not displayed"
… By default RPs could expect an image was displayed. I'm suggesting that rather than show an error, we could just indicate in the response that the image was shown or not. RPs can choose to consider this in their risk evaluation.
… there might be NON ERROR reasons to not show an image (e.g., constrained display)
ChrisD: If I've understood correctly, if the browser cannot load the icon from the RP, that results in failure. I think that is an issue that can happen more frequently than one thinks, and that it sould likely lead to payment failure if it did.
… One reason it may be more likely than one thinks is that there might be different service levels between payment servers and image servers.
Rouslan: First, I think that SPC is essentially used as a step-up (in 3DS terms)
… it is quite possible that the user uses an existing card on a new device
… it's normal in that case for SPC to fail, and that should result in some other form of authentication.
… nothing in SPC requires that the icon has to come from the bank.
… data URLs can also help against server issues
... I like AdrianHB's idea regarding an explicit bit to say the image was shown. But I doubt we would add it to the spec just yet. But please raise as an issue
Action: AdrianHB to add an issue about an explicit bit in the signature whether browser displayed image
<Zakim> ChrisD, you wanted to challenge whether SPC can rely on another authentication method being used as a fallback
ChrisD: I heard Rouslan say "We don't need to make SPC super resilient in the face of image non-availability" since we can fall back to other authentication mechanisms. And I kind of understand that. It feels to me that wherever you add friction, you increase the risk of abandonment.
… I'm not sure there are benefits to not providing a recovery mechanism for failed image downloads.
Stephen: If we allow for a failed image download, the user will see UX. What if the RP does not accept that? What if the RP really wants the icon to be shown?
… but the user experience would be for the user to confirm then get a second step up (e.g. OTP) because the RP did not accept the image not being show
… today, the failure is silent, so there's no extra user friction when there is a failed download.
<AdrianHB_> Or we need to do both...
ChrisD: I would need to think more about whether there should be some alternate user experience provided that the RP has indicated that it accepts the alternate UX if the image cannot be downloaded.
rouslan: In response to the question about 3DS, when were working on adding SPC to 3DS v 2.3, some members of our organization were very aware of image download reliability issues, and pushed to ONLY allow data URLs. We got pushback on ONLY using data uRLs. So 3DS v 2.3 allows both kinds of URLs.
… +1 to the note on data Urls as we suggested
<AdrianHB_> lots of reasons to ONLY support data URLS
Ian: You could also allow the RP to specify some backup behavior (whatever that might be; e.g., enum of options)
Aleksei: +1 to a recovery mechanism in the API
Stephen: Today Chrome (incorrectly) returns the generic WebAuthn error. What is more useful to the RP?
1) Failure with a proper error message or
2) Transaction completes with signature over error condition
Aleksei: I think second...gives developers some options
Stephen: I hear "fix chrome bug to start"
Stephen: What we have to determine then is next steps.
Action: Stephen to file a bug on Chrome to return a more useful error message when SPC icon image download fails.
Stephen: I am hearing from ChrisD and Aleksei that recovery is useful.
Ian: I invite people to continue to document their use cases in issue 125. Thank you all and see you tomorrow.