Meeting minutes
Adyen/Airbnb pilot
Davor: Our goal of implementing SPC was to reduce drop-off rate in challenge flow of 3DS.
… we have about 10% drop-off rate ordinarily.
… SCA is here to stay, so we want to streamline
… we started working last April with W3C, Airbnb, Google
… in August 2021 we had our first successful SPC payment in Airbnb environment internally
… that led us to Chrome implementation changes
… and then a stable version of the API in Chrome 95
… we are ready to start the Airbnb demo within the next month
… here's a video of our flow
Registration video (long description of registration), Authentication video (long description of authentication)
Davor: We faced some challenges along the way.
… we needed to change our integration a bit to implement a graceful fallback to 3DS.
… one thing that proved difficult was to track instrument enrollment across devices
… we had to choose between "always authenticating" and relying on a cookie. There are advantages to each.
… there is now a UI when there is no credential match; a cookie helps us avoid that UX
Davor: We also wanted to be able to distinguish user canceling and genuine error
… we use a cookie for this as well; if present the error is due to "canceling"
… it's not a foolproof approach but it's the best we came up with.
… if someone uses our integration in an iframe, this iframe can be sandboxed, which can limit or make our integration not work at all
… we hope that, in the next steps, to address these challenges as well as a few others.
… we are satisfied with progress so far and look forward to the demo.
Clinton: There was a password in your flow (that we saw in the video). What was that for?
Davor: That password field is part of our challenge simulator. It's not part of SPC. You need to go through this ID&V before enrollment of the SPC credential.
Rouslan: Please say more about the iframe challenges and what needs improvement.
Davor: It's difficult to simulate this locally. Basically, Airbnb's integration is using a sandboxed iframe environment, which, for example, does not allow setting a cookie by embedded code.
smcgruer_[EST]: There's a general question - how to provide a good flow depending on whether user is enrolled or not enrolled, without leaking information.
… WebAuthn says "use a cookie" but in these payments flows we are operating in a 3p context
… and we'll be talking later this meeting about a future with no 3p cookies at all. I don't have suggestions right now
AdrianHB: I have an idea. ;)...
A design goal from a long time ago was for the browser to mediate on behalf of the user, and to enable streamlined flows without revealing too much to the merchant site.
... I think PR API and Payment Handlers could help address the issue that was raised.
… Davor, have you thought about using SPC with other payment methods?
Davor: Personally I have not thought a lot about that yet (but my colleagues may have).
Antoine: Within Adyen we have had some discussions about using SPC in different contexts for delegation of authentication under PSD2. In open banking, for example, there are some challenges distinct from cards.
… so the current focus is on refining our approach with cards before looking at other methods
... But some other payment methods might be interested in this.
... The major challenge with other payment methods is that incentives are different (e.g., iDeal has a well-established SCA approach already)
... In Brazil SPC might be useful for debit card payments, for example.
… but I do think that we'll see more usage of SPC
NickTR: I'd like to continue the conversation around FIDO Europe WG who are talking with banks about FIDO for login.
… I think if we get traction in that space, then SPC could be used "sort of for free" in an open banking context
… we need a concerted cross-industry effort to get there
Antoine: If issuers ask us to use SPC we'd be happy to do so.
… but I agree we need an industry-wide push
… issuers think first about COMPLIANCE rather than reducing fraud or user experience
… we need to develop our messaging to speak to that audience
... We need, say, top 20 issuers in Europe and the rest will follow
<Zakim> rouslan, you wanted to wonder out loud about conditional ui
rouslan: i hear some concerns about "no credential found User Experience"
… additionally we thought it was not going to disrupt the flow a lot.
… but if you feel that it is an issue, do you think that Conditional UI might be a better approach?
… the privacy of SPC comes in part from an ability to not be able to distinguish "no credential" from "cancel"
… the UX is there to prevent a timing attack
... With Conditional UI, the api returns a promise that "hangs." The "hanging" of the promise means either credential not found or user canceled.
… I think with a hanging promise we can avoid the UI
… if this is of interest please let us know
[Say +1 if of interest!]
<aleksei> +1
<Gerhard> +1 to know more
<clinton> +1
<benoit> +1
<AdrianHB_> +1 to learn more about what a "hanging promise" is
<ChrisD> +1
<Eric Alvarez> +1
Gerhard: It would be interesting to build an open banking prototype to understand issues in more detail.
... With open banking a flow exists where you just pick your bank. You are redirected to the bank site (and no information is shared with the merchant).
… in the general flow, your identifying instrument has not yet been shared with the merchant
… but using SPC in this context MIGHT therefore leak more information than in the general open banking flow
… we need to be attentive to that
Alain: "Signed payment request" has been pushed in the Berlin Group but there is no enthusiasm to implement the change request.
<Gerhard> Question: Would Alain be able to share details around those proposed changes?
Alain: if people here would find it useful to do SPC in open banking, we may need to apply additional pressure.
NickTR: Ian, Adrian, and I spoke with them a month ago.
Ian: In that call, the Berlin Group indicated that (in early September) they would be meeting to discuss their roadmap. It was possible that signed transaction data would re-emerge, and if so then we would likely increase our discussions around SPC. I need to follow up with them (and plan to do so after this week of meetings).
PayPal Discussion of User Recognition
Gargi: Recognizing the user is an important topic. We've been talking a lot about privacy at this meeting. Most browsers allow customers to manage cookies and allow them to delete data.
… how are we thinking about tracking registrations going forward?
… how do we keep track of returning devices?
... When you register a device? Are you seeing that privacy settings are making it difficult to track registrations?
… how do you avoid re-registering customers?
Davor: We have seen it happen. If the user's browser deletes the cookie or 3p cookies are not allowed, we go through enrollment again.
Gargi: It's great that customers are increasingly privacy aware.
… a lot of our identification relies on cookies.
Ian: We'll have some discussion tomorrow on user recognition.
Clinton: Yes, this is a challenge, especially with cross-browser availability
smcgruer_[EST]: On the browser front, the general thrust is that privacy be respected and changes are possible with user consent and understanding. And the browser can share more information when there is user awareness.
<clinton> +1
Gargi: From a consent management approach, can there be out-of-the-box integration with browser?
Ian: See the Storage Access API. We have also had conversations about the Credential Management API (and other approaches as wel).
smcgruer_[EST]: Roughly speaking, the API intends to give user ability to share storage, with consent.
… but there are some limitations to that API that don't make it great for payments
… due to partitioned storage approach
smcgruer_[EST]: +1 to exploring this space
Nick_Shearer: I can get some more details on Request Storage as well.
AdrianHB: Part of the problem here is that we are trying to use general solutions for a very specific use case
… we are asking users to give general permissions for specific things, and that tends to confuse the user
… PR API has the advantage of a UX that is specific to payments, and can offer specific behaviors for that use case
<Zakim> rouslan, you wanted to ask paypal whether they have issues with iframes or top-level cookies
rouslan: I agree that if a browser and user could know for sure that a payment was happening, that would be great for users.
… but payments are very complex
… I want to understand the PayPal question more
… in my limited experience, PayPal uses redirects for payments
… in that 1p context you have access to all your cookies
… or are you explicitly interested in cross-origin iframes?
Gargi: Webviews are one conversation.
… The second is sandboxing. For almost all iframes where we redirect for 3DS use cases we are sandboxed
Rouslan: Thank you
Gargi: Because of the lack of information we have, or the customers that we see coming back ... but we don't have a deterministic ID for them. ....we were wondering whether that is a problem for others
<clinton> +1
rouslan: SPC was designed to solve this problem
… what does SPC not solve for you?
Gargi: What we wanted to do with Storage Access (or another approach)
… please help us understand how SPC solves this
<Zakim> smcgruer_[EST], you wanted to muse on Payment Handler as a 1p context
smcgruer_[EST]: Payment handler was designed in this space. Gives access to a 1p context for payments.
… I have some concerns about whether it's payment-specific enough, but it is designed to be a payment context that would support access to the data.
<AdrianHB_> we should consider what a PH without its own UI might enable.
<nicktr> rouslan: people don't want to call SPC if they're not enrolled
<nicktr> ...do we think that the no credentials dialogue is the problem?
<AdrianHB_> +1
clinton: It sounds a lot like some of the challenges we look at with Secure Remote Commerce (SRC)
... The relationship of instruments to users is Many-to-1
… you need a cookie or similar to identify the person
… and independent of the browser from there you determine the available instruments
… the challenge is knowing the consumer before working with them as someone who wants to complete a payment
Nick_S: We don't have a strong position on SPC yet (at Apple). I am interested in the desire to know more about the consumer before payment is initiated.
… I think it really depends on the context in which the payment is made
… I would be interested to dig further into what information people want to know.
<ljharb> eg wouldn't "shipping address" be important, for example, to prevent accepting money if the merchant is unable to ship the user the item?
<AdrianHB_> To answer Nick_S: What payment instruments does the current user have that it can pay with?
<ljharb> that also matters for regional law things - it's not legal to ship alcohol to every state, for example
<AdrianHB_> I believe the solution is sharing payment instrument identifiers in a "non trackable" way. i.e. The user has a payment instrument of type X with a temporary identifier (different for each tx)
<smcgruer_[EST]> ' The user has a payment instrument of type X ' can be a fingerprinting vector
<bdewater> same issue here
<bdewater> @ljharb for regional law things: if I think of Shopify's checkout, the steps are contact info, shipping info, payments. so that determination if alcohol can be shipped would be made before payments
<ljharb> bdewater: ah k
Ian: Thank you all; we will continue the user recognition discussion tomorrow.
I18N joint meeting
Ian: Welcome Internationalization Working Group! There are really two main topics on our joint agenda today:
- Getting shared agreement on next steps related to Payment Request pull request 971
- Understanding the status of the platform-wide approach to JavaScript string internationalization, cf Localizable. This has an impact on both Payment Request and SPC (issue 93)
Ian: For the first topic, the pull request proposes that we go to Recommendation with statements about planned additions. An open question is whether the additions should be one-offs or Localizable. What is the status of Localizable discussions?
Addison: Localizable is kind of stalled, but we think it's the right path forward collectively.
… discussion is whether it belongs in WebIDL or somewhere else
… one clarification on your summary: I'm not quite sure what the proposal is for Payment Request
Ian: It would be an actual Recommendation with hooks. Once we have a clear direction, we would update the Recommendation.
Addison: Our concern is backward compatibility.
… people will want to interoperate with those. If we don't describe "lang" and "dir" from the outset and put normative language around them, we'll be in a state where we have non-internationlized fields
... We'd like to see a platform-wide solution to the degree possible.
Ian: How is it going?
Addison: Slowly. Lots of specs with a small number of i18n-able strings
… I recognize that what you have with PR API is relatively a corner case
plh: It's not clear whether we are going to have a single general solution.
… from a developer perspective, dir/lang would need to be optional (leveraging document default)
… and there are ways to make it backward compatible
nickTR: It's a pragmatic question. it sounds like we can either wait for Localizable on an undefined time scale.
… or put in a 1-off implementation for dir/lang but implementers are unpersuaded because it's an edge case.
1) Wait for localizable, do not publish the Recommendation until that has been achieved.
2) Publish a Recommendation with hooks for future Localizable solution.
3) Publish a Recommendation with dir/lang instead of a platform-wide solution.
<ljharb> smcgruer_[EST]: i missed the context, what JS language feature did you have in mind?
<ljharb> smcgruer_[EST]: hmm - maybe i'm not understanding. what lang does `croissant` have?
Ian: I think it's either #1 or #2 (that's what I'm hearing)
Addison: Personally speaking, it's not our job holding up Recommendations. The WPWG has worked with us well, and I appreciate the willingness to continue to work with us as we navigate the space.
… I don't know if it's helpful overall for us to hold you up from Rec as long as we all have a commitment together to work on resolving the issue..
...putting the right stake in the ground is important.
Ian: What else can we do to be helpful in your conversation about Localizable?
Addision: It is already helpful to say "this is hurting us not having this."
… this is a large multi-year process. It's costly to have lots of 1-off solution.
… that makes option #3 unattractive
r12a: Thank you for agreeing to put a Note into the spec BEFORE recommendation that says "This needs to be fixed but we don't yet know how to do it. We are working on it we will add to the spec."
NickTR: PROPOSED: We go forward with option #2 (Rec with hooks)
<nicktr> +1
<AdrianHB_> +1
<bdewater> +1
Action: Ian to work with r12a on language for a Note in the specification
Ian: I expect to take to GitHub
<benoit> thank you I18N team!
Unlocking the Potential of the Internet of Value
Slides to be included in minutes
Uchi(Coil): We want to change payments on the web to be more Fair, Transparent, Faster
Uchi: Interledger can get us closer to more payments and more payment options for all users.
… see more information at interledger.org, github.com/interledger/rafiki
… and fynbos.dev
Uchi: I look forward to collaborating with all of you to unlock value on the Web
Rouslan: Is there anything that you envision a browser can do that would be useful for users in this space that cannot be done with a JS library?
Uchi: Improve Web monetization spec. And implement Web Monetization natively. There's also an opportunity for a wallet system in the browser
<Zakim> AdrianHB_, you wanted to also respond to rouslan
smcgruer_[EST]: We've invited Coil to contribute to the Chromium open source project. At this point I don't think the Chrome team has resources to invest in this directly, but we are very interested in the space.
Uchi: We also have some opportunities through the Interledger Foundation
… which can support work by engineers on open source code bases
nicktr: What are Coil plans regarding Payment Request?
Uchi: I am open to advocating Coil's involvement in these APIs
NickTR: Thank you, Uchi
<benoit> thanks Uchi!
[Adrian struggles with Audio]
<AdrianHB_> There is an example of browser integration done in Firefox
<AdrianHB_> There are grants that have been made available for technical scholars to experiment with other browsers
<AdrianHB_> Coil will likely try to use SPC for payments when it's own product evolves to making discreet payments like tips/donations
NickTR: I'm excited by the work on ILP, Rafiki
… I am hearing interesting use cases like bi-directional micropayments for streaming content. There are 1000s of use cases for that.
Tomorrow
NickTR: Thanks everybody who spoke today.
NickTR: ...tomorrow: Web Authn. Frictionless flows and user recognition