W3C China organized a Web Technology Forum in June 2023, which was held as a hybrid event with the main in-person hub in Beijing. We are now pleased to share the report of the event, including recorded videos of the 20 talks during the forum (English and Chinese captions are available).

The forum gathered the Web community in China, nearly 100 onsite attendees and over 17,000 watching the live streaming, discussed the latest Web technologies and identified the possible requirements for Web standards.

The forum was kicked off by Philippe Le Hegaret (W3C Strategy and Project Management Lead) giving an overview of the Web standardization work on Web Neural Network, Machine Learning, Security, Private Advertising, WebRTC, WebAssembly, WebGPU, WebTransport, WebCodecs, WCG, HDR, Incremental font transfer, DID/VC, WCAG and Sustainability.   

The Secure the Web Forward W3C Workshop brings together experts in standards and best practices needed to secure Web Applications, practitioners of Security Supply Chain in Open Source contexts, developer advocates with a focus on security and developers, designers and technologists with experience in adopting and deploying Web security standards and practices. We aim to develop a comprehensive picture and roadmap to address the challenges Web developers face in ensuring their applications are secure.

The scope includes:

• How to bring the “secure software supply chain” approach to the web development community.
• Guidance for different types of web developers who work at different levels of the stack.
• How to make emerging web application security standards and technologies easier to use and adopt by web developers.
• How can open source security focused efforts better support the web developer community?
• How can Open Source security review processes serve as inspiration for review of new web specifications?

Attendance is free for all invited participants and is open to the public, whether or not W3C members.

W3C's annual conference TPAC 2022 concluded in September when our Community was able to meet in person for the first time in three years.

The conference was in hybrid format. The main in-person hub was in Vancouver, Canada, with over 360 on-site participants. Meanwhile, TPAC 2022 fully included the remote participants in our meetings and offered them the possibility to be participate actively in the discussion.

What attendees said - How TPAC 2022 went

“TPAC is taking Covid measures extremely seriously.”
Our Events Planning team always puts the safety and experience of attendees at the very first place. They worked hard to set up appropriate health rules, carefully taking into account various requirements such as the evolution on the health situation and its impact on the attendees.

"Just really nice to see everyone again and have somewhat organic conversations over some coffee or a lunch, or during a walk." - Though hallway and informal conversations are the main TPAC assets, this year we gave higher priority to making sure TPAC was a safe place and therefore had to limit the contacts among participants. To support attendees' social demands to the biggest extent, lunches and breaks were more staggered than usual and attendees were given the option to have their breaks and meals outdoors.

"Also the organizers did an awesome job ensuring people could participate in every meeting remotely." - Provided by our technical support team, audio and video equipment was available in each meeting room ensuring a good experience both for onsite and remote participants. The remote participants were also able to attend the plenary sessions which have been video-broadcasted.

"It’s great to see so many important players gather around the same table..." - The event brought together W3C technical groups, the W3C Advisory Board, TAG, Advisory Committee, and the public, to network and work to resolve challenging technical and social issues. During TPAC 2022, the Working Groups, Interest Groups, and Community Groups held 90 meetings gathering a global community of web developers, architects, and product teams to advance standards development on emerging web technologies, to make the web work for everyone.

The technical plenary day, consisting of 45 breakout sessions, offered a great opportunity for everyone to meet and liaise, brainstorm ideas, and coordinate on a wide variety of topics relating to W3C activities, ranging from Web Components, Privacy, Accessibility, WoT, Open UI, Web Monetization, Digital Twins, WebViews, Trusted Web, Multicast, Web3, Sustainability, W3Cx Online Courses, Web Developer Experience, W3C Member Support, just to name a few.

During the AC open session, W3C CEO Jeff Jaffe presented “W3C Strategy, past, present, and future” on the W3C launch as a new legal entity in January 2023, and the AB proactively communicated with members about the transition plan and progress.

The Developer Meetup gathered the global Web community to coordinate the development of Web standards, and delivered four talks during the event, which illustrated how W3C community paves the path of creating solid Web standards, from incubating an idea to a deployed standard that people can reliably use and adopt. See more in W3C DevMeetup report – Vancouver, 2022.

Given the travel restrictions and time differences, W3C/Beihang Host organized a TPAC China Hub in Hangzhou to provide an in-person gathering place to support sessions that are particularly relevant to the Chinese community, covering topics around metaverse & Web 3.0, multimedia & WebTransport, Web Editing, MiniApps and Accessibility. The Chinese Member meeting also debriefed about the W3C Legal Entity transition plan and its potential impact.

Next meetings

We are looking forward to the next annual conference, which will be held in Europe. More information coming soon.

After a three-year hiatus, W3C held TPAC 2022 in person in Vancouver. It was really great to be back in person, and I heard that sentiment from just about everyone. More than 360 people registered to attend TPAC in person and another 250 joined remotely.

Below I summarize discussions of the meetings I attended: the Web Payments Working Group, the Web Payment Security Interest Group, and joint meetings with the Web Authentication Working Group and the Antifraud Community Group.

Web Payments Working Group

The Web Payments Working Group agenda opened with a focus on Secure Payment Confirmation (12 September minutes):

• Adyen and Airbnb shared some information about their SPC pilot. The discussion led us to topics such as the importance of user education (for the new user experience), some ideas for the timing of user registration (post-transaction), and the potential value of sharing a FIDO attestation when using SPC in a delegated authentication flow.
• Google presented their current work to bring SPC to Chrome on Android. That led to discussion about (and strong interest in) SPC availability beyond browsers in native Android apps.
• FIS shared thoughts on three topics of interest: shops making the transition from brick and mortar to digital-first, online stores looking to create a seamless shopping experience, and merchants that prefer strong control over the user experience. Across these topics there were three main themes:
  • Merchants want to know who their customers are prior to authorization. On this point we discussed the impact of tokenization and potential benefits of ensuring that the Payment Account Reference (PAR) can be communicated during an EMV® 3-D Secure transaction that involves SPC.
  • Data is not always available based on payment types or implementations.
  • Cart abandonment is a problem due to extra friction and payment problems.
• Microsoft shared some perspectives as a merchant that adopted strong customer authentication in Europe. They emphasized the important of frictionless authentication and indicated (as FIS also indicated) that stronger authentication can lead to cart abandonment; see the Microsoft slides for details. Key takeaways were thus that a great SCA user experience is very important (hence our emphasis on SPC) but that frictionless risk assessment is still very important. Microsoft reiterated during the talk that merchants do not like to hand over the authentication experience to banks, which, to me, reinforced the value proposition of SPC where merchant controls the authentication ceremony, and the bank can still validate the results.
• We then revisited some EMVCo observations about SPC and some changes that the EMVCo 3-D Secure Working Group has requested, including support for non-payments use cases, recurring payments, and more alignment with user experience requirements defined in the EMV® 3-D Secure specification.

We opened the second day of the WPWG meeting (13 September minutes) with discussion about the Payment Request API, which advanced to Recommendation just before the start of TPAC. Both Apple and Google expressed interest in restoring some capabilities related to address collection that are implemented in their respective browsers, but that were removed from version 1 of the specification for privacy-related reasons. I expect the features will be re-introduced so that interoperable implementations are documented, even if not recommended in their current form. The Working Group is likely to try to evolve the feature to address the previously registered privacy concerns.

After that:

• Apple then described some changes to ApplePay.js over the past couple of years that could be integrated into Payment Request. This was useful for helping the group develop a potential roadmap for new work on the API.
• We then discussed some upcoming changes to browsers related to "Bounce Tracking Mitigations." Bounce tracking refers to very quick redirects from one site to another and back, usually without the user knowing that the redirect has happened. As with previous discussions about privacy-related changes to browsers (e.g., IP address masking, user agent string masking, removal of third party cookies) we discussed the likely impact on user recognition and fraud prevention.
• In the same vein, we then heard about changes that the Chrome team plans to make to their Payment Handler implementation based on other changes on the Web related to privacy. The theme of data collection and risk mitigation continued into the Thursday joint meeting (below).

Tuesday Joint Meeting

On Tuesday afternoon, four groups met: the Web Payments WG, the Web Payment Security IG, the Web Authentication WG, and the Antifraud CG (13 September joint meeting minutes):

• The Antifraud CG, launched in early 2022, has developed as set of use cases; these include both payments and advertising use cases. Proposals to address these use cases are emerging, and we heard about several of them during the joint meeting, in particular about device integrity attestations. We also discussed trust tokens, currently in development in the Web Incubator CG.
• The Web Authentication Working Group summarized the state of specification and deployment of passkeys (cross-device FIDO credentials) and device public keys. I have the impression that device public keys —not yet implemented— could play an important role in payments use cases so that a Relying Party make make risk decisions based on previously seen devices. Those decisions may also rely on attestation availability, and it was pointed out that attestations are optional with Device Public Keys and may not always be available. We then discussed technology developments around a user experience question that we've heard before: if, for privacy reasons, a party cannot query the browser to determine whether the user has already enrolled credentials, how does that party know when to offer the user a registration experience?
• In the final session of the joint meeting, we discussed the status of SPC and broached several topics of ongoing coordination with the Web Authentication WG. We heard that our proposed "cross-origin bit" is now part of FIDO CTAP (and will be made public soon). The Web Payments Working Group next needs to register the extension with IANA. The WPWG re-raised the topic of cross-origin credential creation, which is permitted in SPC but not in Web Authentication. While there is some support within the Web Authentication WG to reconsider this capability in Web Authentication Level 3, there is not yet consensus.

Antifraud discussion, in particular about Device Public Keys used for fraud prevention, continued during a Wednesday breakout on Antifraud.

Thursday Joint Meeting

On Thursday, both the Web Payment Security Interest Group and the Antifraud Community Group held individual meetings as well as a 90-minute joint session on patterns of payment fraud (15 September WPSIG/Antifraud minutes):

• Entersekt presented some payment fraud patterns (e.g., account takeover through phishing, SIM swap, or social engineering; chargeback fraud, and card skimming attacks). We discussed current mitigation techniques (e.g., IP address monitoring) with attention to how those might be affected by privacy-related changes to browsers. As it was put in the meeting, "Browser fingerprinting is not good enough anymore." Our colleagues from Entersekt evaluated some of the Antifraud CG Proposals in development to see which might help with payments fraud use cases. I anticipate we will soon discuss a proposed new risk signal based on the joint discussion.
• Our colleague from the University of Illinois Chicago presented findings from research Phish in Sheep's Clothing: Exploring the Authentication Pitfalls of Browser Fingerprinting. One interpretation of the research is that it illustrates the limits of current approaches data collection used for payment fraud mitigation.

We made good progress at TPAC in understanding use cases, formulating the value proposition of SPC, and emphasizing the need for more fraud prevention tools (with some useful whiteboarding in the mix). I anticipate the groups will want to meet again in person well before TPAC 2023.

TPAC 2022 will be a hybrid event: in-person in Vancouver, with remote participation. I believe more than 600 people have registered, and it looks like more than 350 people will attend in person. This will be my first in-person meeting in about 3 years.

I have been working with multiple groups on a coordinated agenda about payments, authentication, and fraud prevention:

• Monday and Tuesday morning: Web Payments Working Group
• Tuesday afternoon: joint meeting of WPWG, Web Payment Security Interest Group, Web Authentication WG, and Antifraud CG
• Wednesday afternoon: Breakout sessions
• Thursday: Web Payment Security IG, with joint discussion about payment fraud patterns with the Antifraud CG. That agenda link requires W3C Member access.

I'm looking forward to discussion about Secure Payment Confirmation (SPC). We expect to hear about a pilot from Airbnb/Adyen, emerging support for SPC on Android, and other industry perspectives about the current version as well as next use cases.

I'll summarize the meetings in a few weeks!

In early May the Web Payments Working Group held an energetic remote meeting; see the agenda and minutes.

While we were meeting, the FIDO Alliance released a press release with headline Apple, Google and Microsoft Commit to Expanded Support for FIDO Standard to Accelerate Availability of Passwordless Sign-Ins. This type of strong industry support for Web Authentication/FIDO is very exciting because Secure Payment Confirmation (SPC) builds on those technologies and benefits from the momentum.

In preparation for advancing SPC to Candidate Recommendation we have been working through our issues list and stabilizing the version 1 feature set. We closed 7 issues in the past month including through joint discussion with the Privacy Interest Group and the Web Authentication Working Group. We have also labeled some issues as "after version 1." See below for details about how we plan to manage the remaining 10 issues.

At the meeting we heard a bit about recent changes to the Chrome implementation of SPC and upcoming plans. Modirum colleagues provided a demonstration of their EMV® 3-D Secure implementation (version 2.3) that integrates SPC. Airbnb and Adyen shared a brief update on their SPC pilot. We will continue to look for support in more browser engines and refine the specification based on feedback from pilots.

We also discussed Web Authentication more broadly. Best Buy has deployed Web Authentication for login and shared some of their experiences with the group. We also heard about some PSD2 use cases from (French bank) BPCE. In addition to SCA and dynamic linking for payments —the use case for SPC— they have similar requirements for authentication and signatures over transactions involving sensitive data. General browser support for signing transaction data with authenticators has been discussed previously in the Web Authentication Working Group; our recent joint discussion with them may re-energize the topic.

Remaining Issues

Here is a quick summary of our remaining 10 issues and how we plan to address them on the road to Candidate Recommendation.

Web Authentication Topics

The bulk of our remaining issues relate to the SPC dependency on FIDO. In some cases, we think the proper long-term solution will involve enhancements to WebAuthn and/or CTAP:

• Issue 12: support for roaming authenticators. This issue involves both UX challenges and the need for support in CTAP for silently querying roaming authenticators for available credentials.
• Issue 124: determining when to enroll the user (in a way that protects user privacy)
• Issue 157: support for a "cross-origin" bit and CTAP; issue 154 relates to this and is about user consent to allow cross-origin reuse of a credential>.
• Issue 175: impact of multi-device credentials on SPC.
• Issue 187: improving understanding of who is authenticating for whom

I expect the Working Group will try to (1) balance the desire to advance SPC to Candidate Recommendation in a timely fashion with (2) remaining in sync with FIDO advances. It may be that SPC implementations support short-term solutions to some of these issues (e.g., involving caching information) and then evolve as underlying specifications support new capabilities.

Privacy Topics

Stripe asked in issue 172 how to enable a user to opt-out of stored payment credentials for compliance with regulation such as GDPR. In scenarios where the user authenticates in a first-party context, it is straightforward to offer an opt-out feature. With SPC, authentication may happen in a third-party context where it is less obvious how best to offer an opt-out solution. We have been discussing when it would be most appropriate to provide the user with information about how to opt-out:

• At registration time.
• At transaction time, before authentication starts
• At transaction time, during authentication. Overall I've not heard much support for opt-out during authentication.
• At other times.

These discussions are ongoing; Stripe plans to conduct a deeper analysis of their requirements.

I raised issue 77 with the hope that we would find a technology solution to preserve privacy as SPC credentials are shared across origins. We have not found a practical technology solution. Our current plan (see pull request) is to provide guidance to relying parties and others on how to manage identifiers.

Internationalization

Our issue 93 on the localization of displayed strings is shared with other groups (including Web Authentication) whose specifications involve data outside of markup. I believe the Internationalization Working Group will seek support at the JavaScript level in the long run. In the short run, I would like to see W3C publish a standalone specification that describes how to support localizable strings, and that can be "imported" into SPC and other specifications.

UX Topics

In order to better align with EMV® 3-D Secure requirements we've received a request that the Chrome implementation of SPC display larger icons (issue 184). EMVCo colleagues have also suggested additional UX enhancements such as the display of additional icons.

I look forward to our next extended meeting —TPAC 2022 in Vancouver— by which time I hope that we will have reached Candidate Recommendation (or come very close).

The Web Payments Working Group held a remote meeting 25-28 October (agenda, minutes) as part of TPAC 2021.

The meeting took place one week after TPAC breakouts, which included sessions I think were of particular interest to the payments industry, including: Anti-Fraud for the Web, The State of Web Monetization, Cross-Device Security (caBLE), The state of browser storage partitioning, and The intersection of Web Monetization, the Creative Economy and Diversity. Some of these topics infused the Working Group agenda.

The main themes of our agenda were: strong authentication, user recognition and privacy, and Payment Request reviews. In addition, we heard updates on two incubation topics: Google on Digital Goods API and Coil on Web Monetization.

Strong Authentication

On Monday we jumped into discussion about Secure Payment Confirmation (SPC), our primary deliverable related to strong customer authentication (SCA). The Chrome team reported on implementation status, including the fact that SPC support now ships in Chrome 95 stable. We also made progress on some key SPC issues.

On the second day Adyen described the SPC pilot they are currently running with Airbnb. I recommend checking out the user experience featured in Adyen's registration video and Authentication video; descriptions are available.

We met with the Web Authentication Working Group on the third day to discuss care and feeding of the relationship between SPC and Web Authentication. For example, in the current draft specification SPC credentials are FIDO credentials with subtype "payment." SPC credentials can be used for login use cases, but (at least in the current implementation) vanilla Web Authentication credentials cannot be used with SPC. In the current model, it is not possible to alter the nature of existing credentials (from vanilla-to-SPC or vice versa). This led to conversations about whether the ecosystem might find itself creating SPC credentials "by default" to make them useful for both login and payments. We also discussed ways to help FIDO server operators avoid accidentally allowing an SPC credential to be used for login use cases.

The Web Authentication Working Group also shared their vision for new features in WebAuthn Level 3, including:

• Delegation (of authentication rights to others).
• User experience improvements. Relying parties may at time hesitate to use Web Authentication because they don't know whether there is a credential on the current device. The label "non-modal UI" was used to refer to mechanisms that would help create an acceptable user experience without revealing device information to the relying party.
• Support for relying parties signaling a desire for re-authentication.
• Backups and recovery, including potentially synchronizing keys across boundaries (that is, not requiring all keys be hardware-bound).

In the current implementation of SPC, any SPC credential may be used by any origin to initiate an authentication ceremony. During the meeting it was suggested that some relying parties might want to benefit from the transaction confirmation dialog, but might not want other origins to be able to initiate the authentication ceremony. (Following the meeting we logged this as Issue 157: Consider separating the SPC powers of Third Party invocation and Payment display.)

That topic in turn suggested that the current implementation of the SPC credential as a "payment" subtype may not suffice. And the current implementation prevents credential behavior from changing over time: a credential cannot start life as a login credential, be changed with user consent into a login+payment credential, have the login power revoked, etc. I anticipate ongoing productive discussions with the Web Authentication Working Group about which functionalities migrate from SPC to Web Authentication and keeping everything in sync.

User Recognition and Privacy

SPC is gaining traction as our mechanism for strong customer authentication for Web payments. However other user recognition use cases also remain of high interest. At least for now there seem to be two important user recognition use cases:

• Risk calculations. For example, the EMV® 3-D Secure Protocol "frictionless flow" relies on data collection for risk assessment, and some aspects of that data collection may become more difficult as browser behaviors change around cookies. (We had already begun to document some requirements related to EMV® 3-D Secure.)
• Stored user profile information available cross-origin. Some applications want to know who the user is in order, for example, to display that user's available payment instruments.

For the risk calculation use case, our colleague from Entersekt described the pertinent question this way: Have I seen this user on this device with this instrument, and has the user consented to be identified with this device to make this payment experience better? We heard that billions of transactions fail due to inadequate risk assessment, and so this is a serious problem that requires attention.

Can we devise a browser capability to help minimize friction in the user payment experience (e.g., no additional challenge to the user after pushing the "pay" button, no redirects to a first party context) while protecting the user's privacy (e.g., by not sharing strongly identifying information silently across origins)? We acknowledged that there are other anti-fraud use cases that might (or might not) overlap in scope so we should join those discussions. We also recognized the need to be attentive to the potential for abuse of any strongly identifying capability.

We lightly discussed several ideas during the meeting (please refer to the minutes) and it is clear that there is strong interest in more discussion of these use cases.

For conversations about both SPC and user recognition, we were fortunate to meet with representatives from both the W3C Privacy Interest Group and the Privacy Community Group.

Payment Request Reviews

The W3C Membership recently reviewed Proposed Recommendations for Payment Request API and Payment Method Identifiers; I hope that we will soon wrap up our work on those specifications.

We met with the Internationalization Working Group during our meeting to discuss approaches to support the internationalization of human-readable strings in specifications (both Payment Request (pull request 971) and SPC (issue 93)). The Internationalization Working Group seeks to define a Web-wide approach for specifications to define human-readable strings and so the Web Payments Working Group will likely adopt it as the proposal advances.

Next Steps

I think these are the main next steps for the Working Group:

• Publish version 1 Recommendations of Payment Request and Payment Method Identifiers.
• For SPC:
  • Address SPC issues
  • Make improvements based on pilots from Adyen/Airbnb and Stripe
  • Seek implementation in other browsers, and flesh out the test suite to encourage interoperability.
  • Continue to coordinate with the Web Authentication Working Group, Web Payment Security Interest Group, and horizontal review groups.
• Refine use cases and requirements around user recognition use cases. (Following the meeting an Anti-Fraud Community Group was launched.)
• Recharter. I hope to send our draft charter for W3C Member review within the next month.

A Moment of Gratitude

At the meeting, Adrian Hope-Bailie announced to the Working Group that he plans to step down as co-Chair (but remain involved). The Working Group shared their appreciation of Adrian's commitment. I would like here to emphasize how important Adrian has been to this project and to the Web. And we've had great fun. Thank you, Adrian!

TechEx Europe is Europe’s leading enterprise technology exhibition and conference consisting of 4 co-located events covering IoT, AI & Big Data, Cyber Security & Cloud and Blockchain.

It brings together key industries from across Europe for two days of top-level content and thought leadership discussions.

Key topics include latest innovations within AI & Big Data, Blockchain, Cyber Security and IoT ecosystems, and the impact those technologies have on many industries including manufacturing, transport, supply chain, government, legal sectors, financial services, energy, utilities, insurance, healthcare and retail.

We are building the agenda of the Web Payments Working Group's next virtual meeting, 25-28 October. The meeting is part of TPAC 2021, and so are planning several joint discussions with other W3C groups, notably on topics of Web Authentication, Internationalization, and Privacy. In addition to those conversations, our main focus will be Secure Payment Confirmation (SPC). I anticipate we will discuss SPC experiments (Adyen/Airbnb and Stripe), the integration of SPC into EMV® 3-D Secure version 2.3, other potential integrations, and deployment status in Chrome.

We typically organize some future looking sessions. This time around Coil is leading a discussion on "Unlocking the Potential of the Internet of Value". A session like this is particularly timely because we are in the process of rechartering the group and want to be sure that we can accommodate emerging participant interests.

I expect our agenda to solidify over the next couple of weeks, so check back soon.

If you're a W3C Member, or someone who is familiar with our work, you've undoubtedly heard of our annual Technical Plenary and Advisory Committee Meeting also known as TPAC. If you have not, watch the short video introduction of TPAC, the W3C annual conference. This well-attended and popular event is an important means for W3C to coordinate solutions to technical issues while transcending work group borders. The celebrated Breakout sessions, and most of the meetings are public.

Our TPAC Sponsors help offset the cost of the event. This allows us to spend Membership Fees on our core work - Leading the Web to its Full Potential: 39 working groups and 10 interest groups enable us to pursue our mission through the creation of Web standards, guidelines, and supporting materials. In previous TPACs we've only allowed W3C Members to be Sponsors but one of the issues is that the audience is limited to the TPAC attendees and there wasn't an obvious marketing opportunity. THIS YEAR WE'RE CHANGING THAT!

We're addressing that concern by augmenting W3C's 21st TPAC with a Virtual Exhibition Hall that we will open to the public for the two weeks of TPAC (18-28 Oct 2021)! We have put this sponsorship presentation together to outline the opportunities and benefits at each level of Sponsorship. In addition, we can build any custom package if you're interested in having a unique Sponsorship (i.e., Japanese language translation).

Today, we're announcing that the TPAC sponsorship opportunity is now available to the general public with Web technologies interests, for promotion to W3C TPAC attendees and the public that will come to our exhibition hall. This gives you a unique opportunity to associate your brand with the key activities shaping the Web of today and tomorrow. To get an overview of our current work I recommend reading our most recent W3C Strategic Highlights.

Let's talk about what works for you! Drop me a line at alan.bird@w3.org or send a note of inquiry to sponsorship@w3.org. We look forward to having many of you engage with us and to make the W3C TPAC Exhibition someplace that the users and technologists of the Web --that's most of the world today-- visit during our event.

I want to share two updates from the Web Payments Working Group.

The first is that we are preparing a slimmed down version of Payment Request API version 1 to advance to Recommendation by early August. Privacy and internationalization reviews led us to look closely at features related to requests for shipping/billing addresses and contact information. To satisfy some of those concerns and because the features are not widely used in the wild, our plan is to remove them. Doing so should also make it easier for browser vendors to maintain their implementations of the API, and for the Working Group to add new features. Once we've adopted these changes (following a Call for Consensus to the Working Group), we will return to Candidate Recommendation for a brief period, then proceed mid-July to Proposed Recommendation.

The second topic is Secure Payment Confirmation (SPC). (For an introduction, see the previous blog post on SPC and the Stripe Experiment.) The Web Payments Working Group held a 4-day remote meeting in early April to discuss SPC, including:

• The encouraging results from Stripe's pilot leveraging SPC within EMV® 3-D Secure.
• Consideration of requirements from other payment flows such as Open Banking APIs and EMV® Secure Remote Commerce.
• Initial discussion on the scope of SPC functionality, especially on low- or zero-friction options within SPC authentication.

To focus our SPC deliberations, a few weeks ago we created an SPC task force within the Web Payments Working Group. One of the first goals was to craft a clear answer to the question "What is SPC?" Here is our current draft (subject to change; feedback welcome):

Secure Payment Confirmation is a Web API to support streamlined authentication during a payment transaction. It is designed to scale authentication across merchants, to be used within a wide range of authentication protocols, and to produce cryptographic evidence that the user has confirmed transaction details.

The task force has also taken a stab at answering the question "What is unique about SPC?" and capturing some consumer-to-business user stories. After our work on SPC scope we will progress to gathering requirements and prioritizing feature requests.

In parallel, the Chrome team has launched a second origin trial for SPC and updated developer documentation for those who wish to experiment.

Our work on use cases and requirements, as well as feedback from the growing number of pilots (Stripe version 2, Airbnb + Adyen) will inform the shape and initial capabilities of the API.

Now is a great time to experiment; please contact me or the Chrome Team for more information about participating in the second origin trial.

Not all participants are presented in the screenshot.

This past week, the W3C Distributed Tracing Working Group workshop was held. Workshops are held for many years twice a year by now and help bring people together. This time it was a virtual presence event for a second time. The main topic for the workshop was practical use of specifications. We discussed in-depth scenarios for response headers, adopting specification for other protocols, baggage specification next steps, and battle stories.

We had 15 participants this time - lower than for regular in-person workshop, but higher than the last Virtual Presence workshop. We had attendants from Confluent, Dynatrace, Facebook, Google, IBM, Instana, Lightstep, Microsoft, New Relic, and Salesforce.

The finding from this meeting is that we need to make sure to advertise the agenda with the specific time in advance to ensure attendance for the specific topics.

Response headers

The main addition of level 2 Trace Context specification is addition of a response headers. At this workshop we summarized and prioritized scenarios we are trying to solve with the response headers. A few action items were identified to align the proposal for the adjusted priorities of scenarios and we hope that proposed changes would be better aligned with everybody's needs.

Baggage specification

As the group agreed on the general shape of the baggage specification and discussed the adoption of it with the OpenTelemetry project, baggage specification went into the First Public Working Draft status.

Other protocols

We discussed the current state of all protocols we are tracking implementation for. Issues for these repositories now reflect the list of open questions and we are discussing whether more generic cross-protocols guidance needs to be published by this working group.

Andrew from Microsoft brought for discussion the proposal for trace context implementation for JSON-RPC. See the discussion on JSON-RPC mailing list.We are excited with the increased number of technologies adopting the distributed tracing practices and standards.

Adoption discussions

Morgan described how Google keeps marching towards adopting the standard and deals with transition from older headers to the trace context. It is great to see that some customers may be ahead in adopting standards than some big platforms.

Kanwal from Microsoft gave a deep dive into the problem of tracking external and internal telemetry and how tracestate can be used there. Sampling flag introduces some complication as it’s shared for both - internal only calls and external (on the boundary) calls.

Multiple tracers usage by a single app becoming more challenging with the use of a unified protocol, shared Matt from Lightstep. Daniel from Dynatrace said that tracestate helps a lot in these scenarios to keep traces connected.

Other Daniel (yes, there are two) from Dynatrace shared the success of adopting OpenTelemetry. This is very useful that the open source software is compatible with proprietary software and standards developed by this group helps with this compatibility. Bastian from Instana echoed this success of standardization. There are still some gaps that can be addressed in a spec long term and we need to keep track of real world adoption of our standards.

Summary

There were more topics discussed at the workshop. Different ways to use tracestate, privacy concerns and others. If you want to find out more, read full notes: W3C Trace Context October 2020. Recordings will be posted later on the group website. Previous workshop details: W3C Distributed Tracing Working Group Virtual Presence Workshop, March 2020 | W3C Blog

Distributed Tracing Working Group is a friendly and welcoming group and we will be happy to have you join us. Come to the next workshop, or just come talk to us. There are many ways to communicate: ways to communicate with us.

The agenda of the recent Web Payments Working Group meeting (19-22 October) spanned three broad topics:

• Payment Request API, today and tomorrow
• Streamlining authentication in payments flows
• QR codes and more payment methods

Meeting minutes are linked from the agenda; below is my summary.

Payment Request API, today and tomorrow

We first discussed a plan to finalize Payment Request 1.0: it has shipped in Chromium and Webkit browsers for several years; can be used with Apple Pay, Google Pay, Samsung Pay; and is supported in several merchant libraries (e.g., Stripe and Braintree). After the meeting (and a Call for Consensus) the Chairs announced the decision to proceed toward Recommendation. Version 1.0 provided us with a lot of insights and now we can build on that experience.

Streamlining authentication in payments flows

We then discussed "next version" Web payment capabilities, some of which are already in development. In particular, we saw demos of Secure Payment Confirmation (SPC), designed to streamline strong authentication during checkout by marrying Payment Request and Web Authentication. Here's how it works: Web sites call SPC with Web Authentication credentials as input. If the browser is able to authenticate the user using any of the (previously enrolled) credentials, it will prompt the user and return the resulting assertion to the site. In addition, SPC is designed to support "transaction confirmation" use cases, such as those described in European regulation (PSD2's "dynamic linking"). SPC features a clear and secure display of key transaction details, reduces the total number of user gestures to authenticate, and eliminates the need for the site to open its own window for Web Authentication. Stripe showed a demo that leverages the preliminary implementation of SPC in Chrome 86. The demo is part of a pilot program that Stripe is running to test the hypothesis that users will prefer a low-friction authentication experience using Web Authentication (as part of an EMV® 3-D Secure step-up) to a typical one-time password experience. We look forward to hearing results from the pilot by early 2021.

We then heard from Visa and Mastercard about how SPC could enhance the user experience of EMV® Secure Remote Commerce (SRC) flows. (I apologize for the similarity between "SRC" and "SPC"!). Visa presented slides that show an SRC checkout demo including SPC leveraged by the merchant's payment service provider. Mastercard shared mockups of an SRC checkout where a Web-based payment app uses SPC to streamline authentication.

My colleague from Mastercard referred to these approaches respectively as "the left side" (code running in the merchant site) and "the right side" (payment app code running on the user's device). I appreciated that imagery, which I have similarly expressed in a Payment Request ecosystem diagram (shown in this post) where the merchant site (calling Payment Request) is on the left, the browser is in the center, and payment apps (native or Web-based) are on the right.

We thus heard calls for SPC to be available for both left side and right side solutions. We have heard similar requests related to another user experience enhancement: "in-context display". Today the Chrome implementation of the Payment Handler API includes a "modal window" in which payment app code runs. Chrome displays the origin of the code running in the window at the top, a security benefit. There is general agreement that this modal window, which appears above the underlying merchant context, provides a better user experience than a redirect. In-context display is thus available today on the right side, but not yet on the left. I anticipate we will turn our attention increasingly in 2021 to left side use cases as we continue to revisit Web payments architecture.

To round out our authentication discussion, the co-Chairs of the Web Authentication Working Group gave us an update on the progress of Web Authentication Level 2.

QR codes and more payment methods

We also discussed the following payment methods and use cases, looking for connections to Payment Request, SPC, and our architectural considerations:

• QR codes: QR codes are very popular in some parts of the world, and have gained more attention during the COVID-19 pandemic as a way to communicate at a distance. We heard first from EMVCo, who is developing some new standards in this space. We also heard from two entities that are making use of that work: China Union Pay, and the European Payments Council on Mobile Initiated SEPA Credit Transfers. Our colleagues from Entersekt also shared perspectives on QR codes and Web payments, and these may help us structure our conversations moving forward.
• Open banking: Colleagues from STET and the Berlin Group provided updates on the adoption of their open banking APIs, some challenges they are facing, and some new programs they expect to appear in 2021.
• Web Monetization: Coil (one of the TPAC sponsors, thank you!) shared updates about Web Monetization deployments and a current strong interest in using it for use cases such as tipping and donations. We also learned more about the Grant for the Web, a Coil-led project to boost innovation around Web monetization.
• Real-time Payments (RTP) and bill pay: The Clearing House described advances in the Real-Time Payments (RTP) protocol as well as a bill pay use case where the Payment Request architecture could be a good fit for enabling streamlined checkout using the "request for payment" functionality developed alongside RTP. We also connected this discussion to our QR codes and authentication discussions.

Closing thoughts

Although I longed to see colleagues in Vancouver, I found this meeting invigorating and productive (as I found our April 2020 meeting). There is a lot of experimentation happening right now, and I look forward to hearing the results in early 2021, and of course sharing them in this forum. Thanks to the Web Payments Working Group participants for all they do!

A few days ago we launched a new Merchant Business Group focused on non-technical discussion and advocacy. The group held its first meeting in late October and I hope that soon we'll connect some of their use cases and requirements to the Web Payments Working Group agenda. Contact Nick Telford-Reed or me if you have any questions.

Next week the Web Payments Working Group holds an 8-hour virtual meeting over four days. Our agenda includes:

• Review of the status of Payment Request API as it is deployed;
• Discussion of use cases and requirements for a variety of payment methods and flows, including EMV® Secure Remote Commerce, open banking APIs, RTP® (Real-time Payments), Web monetization, use cases for which QR codes are deemed useful, and other non-card payment systems.
• New APIs and design ideas, including updates on Secure Payment Confirmation (SPC), which couples Web Authentication with Payment Request API to streamline strong customer authentication during checkout.

This meeting is part of TPAC 2020, W3C's annual big meeting.

I look forward to reconnecting with colleagues, even if we are only able to meet virtually this year.

In late May, about 25 people participated in the first code-a-thon (minutes) of the Web Payments Working Group. We organized three, 2-hour videoconferences, separated by 22-hour blocks of time for independent collaboration and coding. We learned a lot and saw some great demos!

Projects

On the first day participants introduced seven topics. Four of those ended up gaining traction, and we reviewed their progress on the second and third days. I summarize them here.

Payment App with Web Authentication / FIDO Provisioning

Before the code-a-thon, our colleagues from Entersekt had developed a proof of concept for Web-based payment app that supports Web Authentication. In this demo, the user has a payment app from their bank, and the bank authenticates the user as part of risk assessment. Entersekt showed us a video with the following two flows:

• Enrollment: While interacting with their bank, the user installs a Web-based payment app. The payment app prompts the user to enroll a FIDO authenticator. In the video the user enrolls via the phone's fingerprint reader.
• Transaction: During a subsequent transaction, the user chooses to pay from the same payment app. The user selects the card to pay with, re-authenticates with a fingerprint scan, enters a PIN, and (after some risk assessment process) the bank returns a proof of payment to the merchant who submits it to complete the transaction.

Within the Web Payments Working Group we have been discussing a vision where payment apps are "first-class objects" in the browser, easily registered and managed via browser settings. We face an important question: "Will users want to register payment apps explicitly or will that create too much friction?" It has been argued that users are familiar with the ceremony of downloading and installing apps from an app store. If we adopt a similar approach for payment app registration, this might help increase the user's understanding of which powers to grant to the payment app.

With that discussion as a back drop, Entersekt worked with the Chrome team to mock up a registration ceremony for their payment app. On the final day of the event they presented a video of a payment app registration mockup. This video only shows the payment app registration and provisioning; the checkout portion of the user experience would be the same as the first video.

This demo is likely to help us advance the conversation about payment app lifecycle and the relationship of explicit registration to trust, privacy, and security.

QR Codes for Multi-Device Checkout

For several years, people have pondered how QR codes might be used as part of Payment Request flows. We saw our first proof of concept during the code-a-thon. Entersekt brought a second demo to the meeting with the following flow:

• The user is shopping in a desktop browser and, at checkout, opts to pay via their phone, leveraging a QR code for communication.
• On the fly, the browser installs a Web-based payment app from the user's bank
• That payment app computes and displays a QR code that represents some information about the transaction, including the amount and merchant identity.
• The user opens a payment app from the same bank that runs on their phone. That payment app scans the QR code and prompts the user to confirm the transaction.
• The bank server updates the payment app on the desktop to indicate that the transaction has been successful, and the merchant receives a proof of payment.

On the last day, Entersekt shared a QR payment video to illustrate the flow, including new consent mockups that they developed with Chrome.

Authenticate to Pay (Minimal UI)

Last year, the Chrome Team and Coil to explore an "authenticate-to-pay" feature in payment apps that reduces the total number of user gestures to complete a transaction while simultaneously incorporating multi-factor authentication. Worldline colleagues expressed an interest in enhancing one of their existing Payment Request demos with this authentication UX. Working closely with the Chrome team, they made progress on their demo over the two days. The Worldline demo was shared a few days after the code-a-thon. Worldline indicated that they would like next to enhance the demo to satisfy PSD2 requirements, e.g., with an issing bank as the relying party.

The animation below also show the "authenticate-to-pay" user experience. At this time it is only experimental, it only runs on Android, and it does not yet leverage Web Authentication. But I think there is sufficient interest that the Web Payments Working Group will continue to develop the idea.

Here's what's going on in the animation: in general payment apps can open windows for user interaction. However, in the authenticate-to-pay user experience, the payment app tells the browser: "if you launch me, I won't open a window. Instead, please display the amount, beneficiary, and source of funds to the user and prompt them to authenticate using these credentials." The browser, not the payment app, opens a small window for authentication. The browser then launches the payment app with the results of the authentication. The payment app does not open a window, but does evaluate the authentication results fed to it by the browser as part of completing the transaction. Because the browser opens a small window, this user experience has been nicknamed "minimal UI."

Mobile Money on the Web

In the past we have had discussions with the GSMA about connecting operator-run mobile money systems to Web payments. The code-a-thon offered us a chance to catch up with GSMA colleagues. Opportunities to bring mobile money to the Web may be growing as smart phones are becoming more common in regions where mobile money is a widely-used payment method.

Although no code emerged from the discussion, Adrian Hope-Bailie did start work on a document for ongoing discussion: Mobile Money and Web Payments. It is possible that we may see more experimentation around mobile money and Web payments through the Mojaloop Project.

Undeveloped Ideas

Although people also expressed interest on day one in the last three topics, they did not lead to further discussion:

• I pitched the idea of demonstrating a comprehensive authentication "cascade" that would provide the "best experience" if supported in the user's environment, or fall back to a variety of alternatives.
• We also discussed two points raised by Airbnb during TPAC 2019: integration of "card-on-file" payments into the Payment Request ecosystem, and leveraging responses to Payment Request for account creation.

On Planning a Code-a-Thon

I think that the success of the event hinged largely on preparation by the participants. Entersekt, Worldline, Coil, and Google had all prepared code or documentation. As always, demos focused our attention, raised compelling questions, and drove discussion. I want to thank all the people who brought code to the event.

The Chrome team helped people prepare by creating a starter kit for people who want to experiment with the Payment Request and Payment Handler APIs. I encourage you to try it out, share your project, and provide feedback on the starter kit.

Some additional notes:

• Time zones created the usual issues for global participation.
• Some participants indicated a tension between participating in the code-a-thon and doing their day job. One suggestion was to stretch out the virtual code-a-thon over an entire week, to allow people to squeeze in more coding and discussion time. I could imagine a schedule where we meet for 2 hours on Monday, 1 hour on Wednesday, and 2 hours on Friday.
• We relied on IRC channels for chatting over multiple days. We did not do enough to ensure that people would have access to discussion even when they disconnected from IRC. We will definitely need to fix that for a future event (by using a proxy, or Slack, or some other solution).

Thanks to all the participants! I look forward to seeing more proofs of concept soon.

Many forces are driving rapid changes in the payments industry, including the ubiquity of mobile devices, regulatory requirements (e.g., PSD2 in Europe), and real-time payments initiatives. COVID-19 is also changing the landscape as more companies move their activities onto the Web and face new fraud risks.

W3C groups and other organizations are developing new Web capabilities to rise to these challenges. To enable secure end-to-end payment experiences, all of these capabilities need to work well together, taking into account the full user journey. I am involved in a number of coordination activities to help raise awareness and foster interoperability, including:

• The Web Payment Security Interest Group, a forum to pursue interoperability of technologies from EMVCo, the FIDO Alliance, and W3C. This group also liaises with other groups such as the W3C Privacy Interest Group (e.g., about browser privacy trends) and the OpenID Foundation.
• A joint task force between the Web Payments Working Group and the Web Authentication Working Group. The primary mission of this task force is to inform Web Authentication capability discussions based on payments use cases. We seek to create education materials to help the payment industry adopt FIDO2.

Conversations have been very productive, and people are beginning to bring forth concrete proposals for using independently developed technologies in creative ways. In some cases, the proposals appear to improve security, usability, and privacy all at the same time. Since that is rare, these are exciting discussions.

Here are a few of the conversations that are taking place.

Authentication

A variety of forces are driving discussions about authentication, notably European regulatory requirements in PSD2 for strong customer authentication (SCA). Here are a few of the topics that we have discussed in this area:

• How can FIDO be used to address SCA under PSD2? See the FIDO White Paper on this topic.
• EMV® 3-D Secure 2 is also positioned to fulfill PSD2 SCA requirements. However, it relies on browser fingerprinting and third-party cookies. Browser vendors are changing behaviors in this space (e.g., changes to SameSite behaviors in Chrome, for example), and this is having an impact on 3-D Secure implementations. We've been discussing new strategies (e.g., Storage Access) to meet industry requirements with superior privacy protection.
• We have also been discussing how FIDO authentication might be used as input to 3-D Secure processes. EMVCo and FIDO in particular are discussing their connection (see this 2018 press release).

Several recent discussions have also looked at how to streamline authentication during payment flows by leveraging both Web Authentication and Payment Request API in innovative ways:

• Dirk Balfanz (Google) gave a presentation on an idea where a relying party could create Web Authentication credentials usable by itself and another origin. This could allow, for example, a user to enroll with their issuing bank, and for the bank to mint a credential shareable with the user's payment handler. This would enable the payment handler to control the user experience of authentication, and to pass on the authentication assertion to the issuing bank for validation (e.g., as part of a 3-D Secure flow).
• In March the Web Authentication Working Group reached a decision that could also improve the user experience of authentication within a payment handler. The decision allows for cross-origin iframes to call Web Authentication get(). This could be useful during a 3-D Secure flow, where the issuing bank wants to perform FIDO authentication, but without a full top-level redirection from the payment handler's origin.
• Adrian Hope-Bailie (Coil) has proposed streamlining authentication by leveraging the same user gesture to initiate authentication and launch a payment handler.
• The same Adrian Hope-Bailie has been discussing a "minimal UI" experience in Chrome (mentioned during TPAC 2019 last fall ) where the user simply authenticates to confirm a payment. I am looking forward to upcoming working demos of this streamlined experience.

Privacy / Storage

Above I referred to browser trends to limit third-party cookie behaviors. In addition to SameSite changes in Chrome, see also Apple blog posts, Mozilla Enhanced Tracking Protection, and Google's plans to make third-party cookies obsolete. These changes have an impact on a variety of Web activities, including advertising, session management, and payment industry risk engines. Discussions about the evolution of Web capabilities are taking place in various fora, including W3C's Improving Web Advertising Business Group.

The Web Payments Working Group has been discussing a proposal that payment handlers open in a third-party context by default. However, payment handlers by their nature involve sharing data across origins, so we want them to be able to easily request first-party storage access. Current conversations with browser vendors involve optimizing how to make payment handlers readily available to users, how to ensure users are aware of them and consent to using them, and how to manage "powerful features" (such as first-party storage access) that might be granted to trusted parties in a known payments context. One idea is that an explicit but streamlined registration ceremony would enable payment handlers to perform better than other out-of-the-Web-box solutions for some use cases.

Changing storage behavior will also affect session management. In our discussions about how to carry out Secure Remote Commerce (SRC) transactions through Payment Request API, we have been evaluating ideas to reduce the friction of user recognition across transactions, in a way that aligns with evolving browser behavior and user expectations. One question I have: is the right approach to make it "easier to get in" than "harder to get out?" That is: can we make it very easy for users to be logged back into a payment handler (or otherwise recognized by some relying party) via something like the Credential Management API? I noticed some developer documentation on using that API for one-tap sign-in, and even automatic sign-in under some conditions.

Transaction Confirmation

Another topic from PSD2 is dynamic linking, which I have heard summarized as "what you see is what you sign." As I understand it, the goal is to have a trustworthy record that a user agreed to pay some amount to a particular beneficiary.

The Web Authentication Working Group formulated a "transaction confirmation" extension to Web Authentication Level 1 for this use case. However, the group recently removed the feature from Web Authentication Level 2 due to lack of implementation. The use case is still of interest, and so we are discussing alternative approaches in the joint task force between the Web Payments Working Group and the Web Authentication Working Group, as well as in the WPSIG. We have started discussion of an early proposal from Adrian Hope-Bailie that leverages trust enabled by the combination of Payment Request API and Web Authentication.

One note on the Transaction Confirmation Extension in Web Authentication Level 1: it remains in that specification in case anyone wants to take a crack at implementing it.

Open Banking

In a recent meeting, the Web Payments Working Group heard updates from multiple European open banking initiatives, including Open Banking UK, STET, the Berlin Group, and SWIFT. We continue to look for opportunities to leverage Payment Request API and FIDO Authentication in open banking flows.

Also in the context of open banking several people have drawn our attention to the Financial-grade API (FAPI); we are just starting to learn more.

Help us Drive Adoption

First I want to thank all the engineers from the many organizations working on these technologies and proposals to improve Web security, usability, and privacy (in payments and other areas). Please contact me if are interested in getting involved in the efforts I've mentioned above.

I also want to mention a new opportunity. FIDO2 is particularly exciting now that Web Authentication is widely deployed in mobile and desktop browsers and support for built-in authenticators continues to grow. If you'd like to help support the adoption of FIDO2, please consider joining the WebAuthN Adoption Community Group.

We are also finalizing our plans for a new group devoted to the use cases and requirements of merchants. Although we already benefit from the participation of some merchants, the Merchant Advisory Group, and some stakeholders such as integrators that enable checkout experiences, we recognize that we need more direct input from merchants about their priorities, such as payment method choice, protection against fraud (as I mentioned at the top of the post), and user journeys. I look forward to sharing more details in the very near future about this new Merchant Business Group.

W3C has been driving a set of discussions around the AR/VR/XR space since our first W3C Workshop on Web and Virtual Reality in 2016.  Since then the work has expanded both the depth and scope of what we're doing and is now under the Immersive Web Working Group.

The W3C Business Development team and Technical Staff monitor various events that are being proposed to see which ones would make sense for us to participate in either as attendees, Sponsors, or Presenters. One such event that surfaced late last year is the XR Intelligence series of events put on by Reuters Events. We were negotiating a Media Sponsorship which would have included a discount for W3C Members to attend XR Immersive Enterprise 2020. But things changed due to COVID-19: the event is now free, and online!

The impact of COVID-19 is being felt across every sector, not least in events where the ban on public gatherings has made it temporarily impossible to hold crucial industry meets in person.  However, the Reuters Events team has transitioned a lot of great content into a virtual, 3-day event and W3C is proud to be a Media Sponsor of that event.

I would encourage you to check out the event site and see the presentations from more than 40 industry-leading speakers. Registration is free which is better than any discount W3C would have been able to obtain!

As people shelter in place due to COVID-19, Web usage has increased dramatically. ISPs, platform providers, telcos, content providers, and most other stakeholders are working to ensure that the network can accommodate the surge. It will be very interesting to see which of these behavioral changes remain commonplace once the crisis subsides.

Two weeks ago, against this preoccupying backdrop —as well as some more playful and colorful green-screen effects on WebEx— the Web Payments Working Group held a big meeting to check in on our activities to improve the Web platform for payments and e-commerce (agenda, minutes).

We reworked our Dublin face-to-face agenda into four 2-hour video conference calls on five topics: payment apps, Secure Remote Commerce (SRC) and Payment Request, authentication, open banking, and merchant feedback.

Improving Payment Apps

In recent months, most of the group's technical focus has been on improving payment apps, the software (Web-based payment handlers or native apps) that people use to respond to payment requests. In particular, the Chrome team conducted a detailed privacy threat analysis, which led to a set of proposed changes to payment handlers. That second link includes summaries of all the proposals, so I won't repeat them here. Together the proposals aim to reduce cross-site tracking, fingerprinting, secondary use of collected data, and unnecessary information sharing.

We devoted a lot of discussion time to skip-the-sheet behavior, that is: when and how to skip the browser's built in UX and automatically launch a payment handler. We heard the following:

• Today only Chromium browsers support skip-the-sheet. Because merchants in particular have a strong desire to understand the user's transaction journey, there was strong support for defining and promoting consistent skip-the-sheet behavior across browsers.
• Today Chrome skips-the-sheet to an already installed payment handler even when an installable payment handler could also be used. That is: Chrome favors installed payment handlers over just-in-time installable payment handlers. The Working Group did not support this approach and a helpful guiding principle emerged from the discussion: by default, a browser should favor user choice of payment handlers over automatic behavior to reduce user gestures (such as skip-the-sheet).
• This principle is likely to play a role in answering another design question: should a browser skip-the-sheet to a payment handler that supports delegation of all merchant requested data, even if another one that does not support full delegation could otherwise be used?
• Similarly, this principle suggests support for a proposal to find and show just-in-time installable payment handlers, even when the user already has one or more applicable payment handlers for a given payment method.

We also discussed a number of user interaction and user configuration topics:

• Good support for requiring user consent (or perhaps in some cases notification) before enabling powerful payment handler features.
• Requiring some form of gesture to grant a payment handler access to first-party storage.
• Requiring some form of user gesture before just-in-time installation and skip--the-sheet can be used in combination.
• User configuration of a "preferred payment handler" to enable more streamlined checkout flows.
• A proposal that a single user gesture be usable simultaneously to trigger Web Authentication and launch a payment handler.

As a next step, we will consider the feedback on the proposed changes and present a synthesized approach to installation and display that improves user awareness and privacy, maximizes user choice, and facilitates strong authentication, all while continuing to streamline transaction flows.

The Working Group also appreciated learning about a recent security analysis of Web Payments carried out as a Master's Thesis. We expressed our appreciation to @crowgames, who has summarized three key findings and already begun collaborating with browser vendors on fixes.

Secure Remote Commerce (SRC) and Payment Request

Our primary objective on the second day of the meeting was to drive toward consensus on an architecture for doing EMV® Secure Remote Commerce (SRC) through Payment Request API. We reviewed in detail a series of flow diagrams for first time users, returning recognized users, and returning unrecognized users.

At a very high level, the proposal leverages the Payment Request toolkit as follows:

• There will be one Payment Method Identifier (PMI) per SRC system. All the PMIs will share a common origin (domain name).
• There will be a "common payment handler" hosted by the same domain. All of the Payment Method Manifests of the SRC systems will refer to the common payment handler as the default payment handler. Having a common payment handler makes it easier to avoid "wallet selection" in the user experience. Instead, when the merchant accepts an SRC Payment method, the browser will be able to skip-the-sheet into the common payment handler.
• Once launched, the common payment handler will only have two roles: (1) to route users to an SRC-I identified by the merchant (2) to store information that will make it easier to recognize a returning user in a future transaction. This approach has the appeal of leveraging existing merchant relationships with SRC-I's as well as deployed code.

Participants raised some interesting points:

• The data model of a future SRC payment method definition will, for the most part depend on the EMVCo specification. However, it will also need to support custom data passed by the merchant to the target SRC-I.
• We need to make clearer whether the common payment handler will the preferred payment handler of the ecosystem or the only SRC payment handler available.
• We also need to continue discussion of how a common payment handler will deal with delegation of merchant requests for contact and shipping information to SRCIs.

Once we have converged on the architecture, we will be able to advance to work on a proof of concept as well as the actual specification of the payment method.

Authentication

Representatives from the Web Authentication Working Group shared updates from their February face-to-face meeting.

We discussed the decision to allow Web Authentication get() but not create() from within cross-origin iframes in Web Authentication Level 2. On many occasions we have discussed the scenario where, as part of a 3-D Secure (3DS) flow, an issuing bank may wish to insert some code in a merchant site or a payment handler. The recent decision means that at transaction time, the issuing bank will be able to call Web Authentication without the need for a full redirect to the issuing bank's site. We hope this will enable a superior user experience at the same time it enhances security and risk assessment.

We also discussed a decision to remove the "transaction confirmation" extension in Web Authentication Level 2 due to lack of browser implementation. The feature had been seen as important fulfilling European regulatory requirements under PSD2 around "dynamic linking." Participants expressed interest in discussing alternatives (e.g., by adding features to the browser to use FIDO authenticator keys to sign information available through the Payment Request API). I anticipate that those discussions will continue in the joint task force between WPWG and WebAuthn.

Open Banking

STET, Open Banking UK, the Berlin Group, and ISO 20022 Registration Authority / SWIFT brought us up-to-speed about various open banking activities, successes, and challenges. Here are some of the points that stood out for me:

• Adoption is growing and the organizations working on APIs continue to revise them.
• Strong Customer Authentication (SCA) remains a challenging topic, especially around the user experience.
• In addition, the Strong Customer Authentication requirement apparently also complicates the accepted fallback solution when the open banking APIs are not available.
• There remains some tension between data collection for risk assessment and privacy regulation (e.g., GDPR).
• The FAPI profile of OAUTH was mentioned multiple times.
• In the UK and Ireland, work has increased on a directory intended to make it easier for Third Party Providers (TPPs) to discover, connect, and validate certificates. The Berlin Group also cited work on discovery given that there will be hundreds of parties interacting and providing services.
• There is a growing set of activities around more use cases, including payroll and business-to-business payments.
• The Berlin Group pointed out that when PSD2 is "tranposed" into national legal frameworks, this can introduce subtle differences in requirements and other challenges to interoperability.
• Our colleagues from SWIFT / ISO 20022 Registration authority discussed their collaboration activities with Open Banking UK and the Berlin Group to harmonize the data model across APIs by leveraging the components of the ISO 20022 repository.

We had anticipated experiments combining open banking APIs with Payment Request and Web Authentication at our code-a-thon. A future virtual event may provide the best opportunity for experimentation.

Merchant Feedback

The Working Group values hearing about merchant experiences with the APIs.

Sumantro Das from 1-800-FLOWERS.COM, Inc. shared his experience working with Payment Request API for the past several years. In the past we have discussed findings that show how Payment request can speed up checkout. Sumantro similarly reported an uplift through Payment Request on product pages from Android. Specifically he cited a number of things he liked, including:

• Flexible user interface
• Built-in support for credit card input (in Chrome)
• Leveraging the API in sophisticated real-time availability of product use cases.

Sumantro also gave an assessment of how Payment Request from several perspectives:

• Security: Good, but needs a refresh
• Timeliness: Good
• Transparency: Good
• Convenience: Good, but needs a refresh
• Usability: Good, but needs a refresh
• Universality and accessibility: needs improvement

He also made some concrete implementation suggestions:

• Allow address type-forward in the sheet.
• Support address auto-correct in the sheet
• Allow users to enter promotional codes or gift cards (split tender payments)
• Leverage strong authentication further

Sumantro also suggested adding greater support for customization (of the UX) and loyalty use cases.

Virtual Meeting Experience

Now a bit on the virtual meeting experience. Although I sorely missed the hallway time of face-to-face meetings, we compensated a bit by opening the bridge 15 minutes early each day for casual chit-chat. If we repeat this type of meeting, I will suggest even more open time.

Because at times 60 people participated, we skipped introductions around the table. Nick Telford-Reed suggested that next time we seek enhanced tooling support, for example being able to easily reach each participant's affiliation and short bio from IRC or WebEx.

We surveyed the participants following the meeting and so far have heard:

• Very strong consensus that two hours was a good call duration.
• Video was generally appreciated, although for some it was less useful due to bandwidth issues.

More useful feedback for other meeting planners:

• Defining clear objectives for each session —generally good practice— proved especially valuable for a virtual meeting.
• Mute all microphones by default
• Real-time scribing (in our case on IRC) is appreciated.
• The IRC channel also plays an important role for comments, quips, and questions.
• Add a bio break

Time zones always post challenges. We appreciate that our colleagues in Asia-Pacific attended late at night. Thank you!!

We may soon have another opportunity for a virtual meeting: we had great plans for our Dublin code-a-thon and there is support for holding an online version.

The co-Chairs and I agree that overall this was a successful meeting, and we might take back some lessons for our future face-to-face meetings. For example, I could imagine organizing meetings so that there is only a half-day of very focused discussion, with long breaks and open sessions for ad-hoc discussions.

Summary of Next Steps

The Chairs and I came away from the meeting really energized and with an emerging picture of next steps in each of these major topics, for discussion with the Working Group in the coming days:

• Payment handlers: There's a growing confidence in the direction and maturity of the payment handler architecture, with great feedback on concrete payment handler proposals. Next we will turn those proposals into concrete pull requests, get review from other W3C groups, and benefit from updated implementations.
• SRC: The Card Payment Security Task Force will continue to build consensus around a proposed architecture, in particular among card networks/SRC providers. However, we welcome thoughts from all the WG's participants and urge them to join the fortnightly task force calls. Once we have sufficient consensus on the architecture the next step will be work on a proof of concept.
• Open banking: It was great to hear so much progress and cooperation among STET, Berlin Group, Open Banking in the UK and SWIFT. We want to continue to collaborate with these groups on a proof of concept that leverages multiple APIs (and possibly our previous work on a credit transfer payment method). Our plan had been to do this work at the code-a-thon in Dublin that we had to cancel. We'd like to tackle this at a virtual code-a-thon, so let us know if you are interested.
• Authentication: We expect our joint task force with WebAuthn to continue to look at dynamic linking use cases as well as the proposal to combine WebAuthn and Payment Handler gestures. This is an area which feels like we need to apply some rocket assist. The solution feels like it's within our grasp, but we've not quite been able to connect the dots.
• Merchant feedback: We heard more support for addressing split tender use cases (including coupons) which have been with us since the start of the group. Generally speaking, we will continue to seek increased merchant engagement in W3C discussions around Web payments.

I want to thank everyone who participated in the meeting and hope to see everyone soon in healthier times. Many thanks to the Chairs for contributions to this post. Let's keep making Web payments better!

UPDATE 2020-03-05: Due to travel restrictions around COVID-19, the Web Payments Working Group does not plan to meet face-to-face as scheduled, but will conduct a remote-first alternative meeting.

Last month, W3C renewed the charter of the Web Payments Working Group through 2021. The new charter is similar to the previous one, but added explicit mention of a Recommendation-track deliverable related to the use of EMV® Secure Remote Commerce (SRC) via Payment Request API.

At the end of March we will hold our next face-to-face meeting in Dublin, hosted by Airbnb. Our agenda is still rough, but I anticipate discussion of an SRC payment method, the status of browser support for Payment Request and Payment Handler, updates from the joint task force between WPWG and the Web Authentication Working Group, some merchant experiences with the APIs, and perhaps some discussion of the current Irish and/or EU payments landscape. Given the strong customer authentication (SCA) requirements of Europe’s Payment Services Directive (PSD2), I also expect a special focus on streamlined integration of Web Authentication into payments flows.

Regarding SRC, between now and the face-to-face meeting, we are working on a succinct description of “how SRC can work with Payment Request.” This would be the culmination of discussions within the Card Payment Security Task Force about data models and user experience requirements and assumptions. It is also an important precursor to a concrete payment method specification. My goal is for the Working Group to come together around “how it will work” during the face-to-face meeting, and then to initiate work on the payment method definition shortly thereafter.

For the first time we are meeting for a total of 4 days. Included is a 2-day "code-a-thon” where participants will demonstrate how Payment Request, Payment Handler, Web Authentication, and related APIs can be used to create compelling checkout experiences for a variety of payment method and authentication flows. I anticipate we will look at SRC flows, ACH flows, and open banking flows. We also heard from Airbnb last September interest in topics such as integrating card-on-file into the Payment Request user experience (for consistency with guest checkout), and using Payment Request as part of account creation. My hope is that the code-a-thon results in proofs of concept, fodder for good practices documentation, and ideas for new features.

I look forward to seeing colleagues in person, and also visiting Dublin for the first time!

The Web of Things (WoT) IG/WG has made significant progress towards our goal of an open Internet of Things based on web standards. At the recent W3C TPAC meeting held in Fukuoka Japan on September 16-20, we once again demonstrated the use of WoT Thing Descriptions to support interoperability between IoT devices from multiple manufacturers. A variety of devices from Panasonic, Fujitsu, Hitachi, Intel were combined with a Web Things gateway from Mozilla as well as services from Oracle and Siemens to target a variety of consumer and industrial IoT use cases. NHK additionally demonstrated an integration of their hybridcast system with WoT, using data embedded in television broadcasts to drive contextual IoT services, such as adapting lighting to specific content.

The following figure gives a concrete example of the main deliverable to date of the WoT WG: the WoT Thing Description. A WoT Thing Description is simply a standardized data format, based on JSON-LD, for providing the metadata for a Thing so that the services and data it provides can be understood and so that it can be accessed by authorized users. It can be used to describe existing devices and services as well as supporting the development of new IoT systems. The intention is to support the integration of IoT systems by allowing a common means for metadata to be exchanged and a common high-level abstraction for network interactions based on properties, events, and actions.

We are now rechartering both the Interest Group and Working Group with work items such as discovery and ad-hoc interoperability in constrained environments. We encourage readers interested in these topics to reach out and engage with us in this exciting work!

Over the past several years the W3C Membership has been working to help address the fragmentation that has occurred in the Internet of Things space. Our work, on Web of Things, seeks to counter fragmentation by making it much easier to create applications without the need to master the disparate variety of IoT technologies and standards. Digital twins for sensors, actuators and information services are exposed to consuming applications as local software objects with properties, actions and events, independently of the physical location of devices or the protocols used to access them.

One of our guiding principles is that our standards need to be implemented in real-world solutions. In order to hear the needs that exist in the various IoT Industries (Smart Cities, Industrie 4.0, Smart Buildings, etc.) the World Wide Web Consortium has been attending and participating in a number of events over the past several years. We have yet to actively involve the IoT community in Australia and by Partnering with IoT Impact 2019 we have that opportunity. I will be attending the Sydney event to listen to the speakers and engage with as many people as possible to expand the discussions in W3C with the thought leaders in Australia.

If you're a W3C Member interested in attending the event, please check your e-mail: there is a 10% discount off registration. If you're going to be there and want to meet to discuss W3C's work in this space, or anything about W3C, drop me a note and let's get together! I'll be in country from the afternoon of Friday, 11 October through mid-day on Wednesday, 16 October.

The Web Payments Working Group met face-to-face 16-17 September as part of TPAC 2019 (agenda, minutes).

The meeting was well-attended, energetic, and brimming with new ideas. I left with the impression that we have a lot to do, but also that we have lots of material to work with, and a growing community to do the work.

The post is long; many thanks to Nick Telford-Reed for helping to make it shorter than it was!

Payment Request API 1.0

To publish our main specification as a Proposed Recommendation we need to address two topics:

1. A Webkit update following a specification change; this is underway.
2. The formal objection previously raised when we advanced to Candidate Recommendation for which there is a proposal for a new feature.

On the second point, the group is now evaluating two options:

• whether to gather implementation experience before requesting to advance Payment Request 1.0 (likely to require a number of months); or
• to request to advance with this feature as optional for browsers to implement.

The consensus of the group is that the feature set of v1.0 is otherwise stable.

Payment Handlers

We believe we need more broad and interoperable support of both Web-based and native payment handlers. An important objective of the meeting was to understand how to encourage additional adoption.

The Chrome team cited a number of benefits of payment handlers, including expectations for higher completion rates, better connectivity properties, lower implementation effort, increased reliability, and improved security. Because payment handlers operate as top-level origins (unlike iframe-based checkout solutions) they provide new opportunities to streamline authentication.

Chrome demoed new features since our April meeting, including full delegation of requests for contact and shipping info to payment handlers, great tooling to aid developers, and a new "minimal" user experience where the user simply sees the total and a prompt to authenticate.

Other suggestions to expand our adoption strategy included:

• Compile and share data that shows increasing adoption of Payment Request and Payment Handlers.
• Conduct more outreach to more merchants, for example via a specialized forum within W3C for merchants to share use cases and requirements.
• Increase our outreach to large payment service providers such as PayPal, Alipay, and WeChat pay to encourage experimentation with payment handlers.
• Organize a hackathon to bring together, in particular, merchants, payment handler developers, and browser vendors to demonstrate the value of Payment Request and Payment Handler.
• Improve tooling and testing for developers

We also looked at possible improvements in interoperability and user experience:

• Chrome supports two popular behaviors that are not formally specified: "just-in-time installation" and "skip-the-sheet". As consistency of user experience is important, we might informatively describe Chrome's implementation and encourage other browser vendors to adopt the same behaviors.
• The Chrome implementation of Payment Handler API includes a secure modal dialog where the payment handler code executes. This may be a useful type of dialog for other use cases beyond payments, which might make it more attractive from a browser maker perspective. Editor's note: Since the meeting we have begun work on a modal window explainer.
• Re-evaluating the role of the "sheet" because:
  • Shopify findings suggested users were surprised by this new UX element.
  • Browser vendors report there is a high cost to maintaining a good UX for the data contained in the sheet.
  • Payment handler developers have asked to be able to handle requests for stored data rather than the browser.
  • Mixing "applications" and "instruments" (e.g., card data) in the sheet may confuse users.
  • Implementers may be able to devise superior "selector" experiences, including optimizations for selection of default payment handlers.

Airbnb Experience with Payment Request

Airbnb saw Payment request API as a means to remove complex billing forms, streamline first-time bookings, connect data collection to account creation, and access more payment methods (e.g., Apple Pay and Google Pay). They shared some of their experiences (slides):

• Ideally Payment Request would be "the one API." However, Airbnb has to provide two flows to support both new and stored cards. They asked: could we integrate cards previously stored by the merchant into Payment Request?
• Could Payment Request give access to label and style information in the sheet to avoid terminology differences between the sheet and a custom checkout?
• Airbnb works with a number of PSPs for both redundancy and method coverage in different regions so additional flexibility in selecting a PSP during a given transaction would be a boon. They advocated "universal tokens," which led to discussion of the relationship with EMVCo tokens.
• Could we unify guest checkout and new account creation with the merchant, ideally as part of the Payment Request experience, so that the user creates credentials and agrees to terms of service? This suggestion raised concerns that adding too much to the API might make it too heavy-weight.

Airbnb would like to see more interoperable support for payment handlers across browsers, and access to more payment handlers, reinforcing the group's observations about the need for more payment handler support.

Card Payments

The Card Payment Security Task Force has been working on a Secure Remote Commerce (SRC) payment method definition. Mastercard showed a new demo of three user journeys:

1. New user who is enrolling a card in an SRC system
2. Returning user on the same device; select a previously enrolled card
3. Returning user but using Web Authentication

The demos included using Web Authentication when accessing a list of candidate cards from SRC systems, and when, on selecting a card, the issuing bank requests authentication.

The demos showed that the user might be authenticated multiple times in some flows, leading us to discuss ways to minimize friction:

• A payment handler might authenticate a user directly, or embed an SRC authentication experience.
• Parties might share authentication results. For example, a payment handler might authenticate the user. Some SRC systems might trust those authentication results, reducing friction when accessing the candidate card list.
• A payment handler might re-use of authentication results as input to a 3DS risk assessment process, making a subsequent 3DS step-up less likely.

We briefly looked at ways to leverage identity known to the browser to simplify SRC transactions.

The Working Group strongly supported continued work by the Card Payment Security Task Force on an SRC payment method definition. Additionally, there was support for 3-D Secure through Payment Request, independent of SRC.

Basic Card

The "Basic Card" payment method is currently supported in Chrome, Edge, and Samsung Internet Browser through "built-in" payment handlers. There are currently no expectations for support in either Safari or Mozilla, which led some people to argue that we should move away from Basic Card and focus on SRC. Others said that Basic Card remains a useful payment method at least in the short term because full SRC adoption will require time, and some merchants many not move to SRC.

We heard another idea as well: could browsers connect Basic Card payment handlers to existing autofill capabilities? If so, users could leverage payment handlers on merchant sites that don't yet support Payment Request.

Merchant and Consumer Pain Points

We organized a session on Consumer and Merchant pain points both to validate that our current work is addressing industry needs, and to identify and prioritize requirements as we recharter the group.

The session organizers pre-selected 15 pain points for discussion. During the presentation, people added a few more:

• Some merchants may not ship to some locations (e.g., smaller countries). One idea to help merchants was to geo-locate the IP address of the user and display a warning at the start of checkout.
• Friendly fraud, such as when a child uses a parent's account to make a purchase (without parental consent) leading to discussion about device profiles and configurations (e.g., "this biometric is authorized to make payments; this one is not."). In practice, segmenting biometric templates raises usability issues and therefore is uncommon.

We then split into four breakout groups for "importance / difficulty" evaluation of the pre-selected pain points. Some preliminary findings:

• Some pain points could be addressed through more widespread adoption of payment handlers.
• Two groups suggested reframing "speed up checkout" as "find the optimal checkout speed." For example, checkout could involve more help for new users, and could involve less friction for repeat customers.
• We need to be clearer in our next conversations about audience: when we say "account-free," what kind of account do we mean? When we say "difficult," which stakeholder does that refer to?

The Working Group will look for patterns across the breakout group findings and otherwise continue to refine the analysis as part of rechartering.

Payments in Asia

We invited colleagues from JCB and SWIFT Asia to share updates on the payments landscape in Japan and Asia more broadly. We heard specifically about:

• A new QR code standard for in-person payments in Japan. Several people expressed support for more work on QR codes for online payments in our next charter.
• SWIFT initiatives around real-time payments in Australia and GPI, which focuses on improving cross-border payments.

We were treated to a demo of GPI through Payment Request API. The demo involved a push payment initiated by the payment handler, which then returned information that enables the merchant track the status of payment within the GPI system.

Web Monetization

The Working Group has discussed Web Monetization at its face-to-face meetings for over a year. We heard about progress on the Web Monetization specification since April.

On the first day of the Working Group's meeting, Coil announced a Grant for the Web, in partnership with Mozilla and Creative Commons. According to the Web site, "Grant for the Web is a $100M fund to boost open, fair, and inclusive standards and innovation in web monetization."

Naturally, we asked how this relates to Web Payments Working Group deliverables. Coil indicated that there is a likely need for both a payment method definition and enhancements to payment handler functionality to support the Web Monetization model. For example, today content providers include a meta element in their pages to indicate where they can receive payment. That could be replaced by calls to Payment Request API.

Web Monetization is called out in our current charter and I anticipate it will also feature in our new one.

Web Authentication and Payments

Several members of the Web Authentication Working Group joined us to talk about their upcoming new features including so-called "TLD+1" use cases, where Web Authentciation may be called from within an embedded iframe. For example, if a Web-based payment handler were to embed code from an issuing bank origin in an iframe, the issuing bank would not be able to use Web Authentication Level 1, but would be able to use the intended Web Authentication Level 2.

We also discussed:

• "Carrying authentication downstream" to avoid multiple authentications (and reduce friction).
• Segmenting biometric templates (or, "authentication profiles") and the accompanying user experience challenges.
• Dynamic linking requirements under PSD2 and how to secure the display for authenticators that do not have their own display.
• Token binding and its potential role in risk assessment.

The two groups agreed to form a joint task force for continued discussion about payments use cases and Web Authentication.

Rechartering

The Working Group's current charter expires at the end of the year. In Japan the participants expressed a strong expectation that we would recharter, so the co-Chairs and I will begin work on a draft to include:

• Completion of Payment Request API 1.0
• Enhancements in Payment Request API 1.1
• Continued work on Payment Handler API
• Continued work on an SRC payment method as well as discussion of identity and user experience issues
• Web Monetization in some capacity

Personally, I think more discussion is required before we include the following:

• Basic Card. I think we need to reach a better shared understanding of the role of Basic Card, and then document that in the charter.
• 3DS support outside of an SRC context.
• QR codes. The QR code discussions we had in Japan focused on physical world payments; I think we need a better understanding of the relationship to Payment Request.

As always, I would like to thank all of the Working Group participants for contributing to this effort. Each year I appreciate the camaraderie and energy boost of TPAC. I look forward to our next phase of Web payments innovation.

I look forward to meeting with colleagues next week during TPAC 2019. I hear that nearly 650 people will be in Fukuoka, Japan over the course of the week.

The agenda of the Web Payments Working Group includes discussions about the current status of Payment Request API and Payment Handler API, EMV Secure Remote Commerce (SRC), merchant and customer pain points in e-commerce, Web Monetization, rechartering, and more.

I plan to write a meeting summary in this space that should be available before the end of the month. Until then!

We are now two weeks away from TPAC 2019, the annual five-day event that allows over 500 people to coordinate the development of Web standards done in W3C's working groups, community groups, the Advisory Board, and the Technical Architecture Group (TAG). Working Groups, Interest Groups and the W3C Advisory Committee will hold their face to face meetings in one place and have the opportunity to meet and liaise with participants from other groups. The Wednesday of that week has 6 hours of breakout sessions: an opportunity for everyone to propose, choose, and participate in breakout sessions on a wide variety of topics relating to W3C activities, and a chance to contribute to discussions and connect with people working on ideas that may not fall within everyone's usual areas of activity.

We are honored and thankful that Coil, NTT and Rakuten Institute of Technology have stepped up as Platinum Sponsors of the event:

Coil was founded in 2018 by Stefan Thomas, former CTO of Ripple, to build a better business model for the web. Coil's platform is designed to make it easy for creators to monetize their content across the internet. As subscribing fans enjoy content, Coil uses an open API called Web Monetization to stream micropayments to creators in real time. The platform supports creators, including writers and journalists, video creators, podcasters, streamers, musicians, photographers, and artists. You may follow Coil on its creator page and on Twitter (@Coil)

NTT Group has provided the infrastructure to support the development of the Japanese industry for a long time. Society is currently faced with varioues issues in Japan. To resolve social issues through our business operation, NTT Group works together with our partners, as "Your Value Partner". The Group is utilizing its various management resources and capabilities, including those pertaining to research and development, ICT infrastructure, and human resources, through its business activities as part of its efforts to resolve such issues. NTT Group are also collaborating with partners and will undertake a digital transformation while supporting customers as they make similar transformations, rooted in our Shared Values the core principles that support our activities “Connect,” “Trust,” and “Integrity.”

Rakuten Institute of Technology launched in 2006 as the dedicated R&D organization for the Rakuten Group. Rakuten Institute of Technology is located in Tokyo, Paris, Singapore, Boston, San Mateo, and Bengaluru, engaging in cross-location projects and supporting the globalization of the Rakuten Group. Our research is divided into function-based research domains named the Power Domain, the Intelligence Domain, and the Reality Domain.

• The Power Domain is responsible for the technical infrastructure on which Rakuten's services thrive. We work on autonomous systems, distributed computing, networking & telecommunications, robotics & automation in general, machine learning and algorithm design, as well as programming languages and anything else that Rakuten requires. Thus we provide the fundament or substrate that supports and enables the work of Rakuten's manifold services as well as the other domains.
• The Intelligence Domain aims to enrich Rakuten's services from the perspective of data. We are focusing on creating structured product data for supporting global shopping experience, providing user-friendly product navigation and optimizing business operations by utilizing various kinds of data related technologies such as natural language processing (NLP), data mining, machine learning and statistical analysis. Most of our technologies are applied to Rakuten's services and are making business contributions.
• The Reality Domain aims to create new user experiences applicable within Rakuten services through prototyping, proof-of-concept studies, and real-world deployments. We are focusing on novel user interfaces and user experience, computer vision, and multimedia processing. Our activity includes transferring practical state-of-the-art technologies into Rakuten's businesses, as well as proposing future concepts and vision.

I will be attending the Financial Innovation and Payments Summit (#FIPS) for the third year in a row!  Last year, I moderated a panel, this year I'm doing that again as well as participating on another panel.

I'm excited to be the moderator for the Evolution of Digital Payments panel and to be joined by Solomon Choi (@Solohandles) of 16 handles (@16Handles),  Frank Liddy (@FrankLiddy) of PayPal (@PayPal), Abhi Kulkarni (@TalentbeatInc) of Aurus, Inc.,  Brian DuCharme (@BrianMobileGuy) of STAR Network, and Rachel Siegel of Pew Charitable Trusts!  This panel brings the experiences from a diverse set of organizations in the Digital Payments space.  We plan to cover both the recent (past 3 - 5 years) changes in Digital Payments as well as looking at what might be next focusing on foreseeable future and playing a little bit of crystal ball beyond that.   Hopefully we'll have some thought provoking discussions and engage the audience as well!  We're on at 4:00P on Wednesday 10 July, so if you're in Newport we'd love to see you!

On Thursday, at 2:15P, I'm honored to be on the Digital Payments Creating Smarter Cities Panel being moderated by Bryan Jurewicz (@bryanjurewicz) of Arrow Payments (@ArrowPayments).  We had our organizing call today and Bryan has put a great set of discussion points together that I think the audience will love and I suspect will cause a level of questioning to occur.

As always, I'm available for anyone attending that wants to learn about the exciting things going on in W3C around Payments, Automotive, Entertainment and Media, Privacy, Security and much, much more.  You can find me on @JAlanBirdW3C, or on the @Opal_Group #FIPS app.