Skip to content

SPC Candidate Recommendation Vision

Jump to bottom
Nick Telford-Reed edited this page Sep 12, 2022 · 38 revisions

Status: This is a vision for Secure Payment Confirmation (SPC) at Candidate Recommendation. This document does not (yet) represent any consensus. Questions? [email protected].

W3C Process requirements to advance to CR are described in section 6.3.7 of the W3C Process Document.

Proposed Timeline:

  • 12 August: Request horizontal review of significant changes since FPWD.
  • TPAC: Discuss any important new horizontal review issues.
  • Post-TPAC: Do process of going to CR: CfC, etc.

Requirements

Process: "must show that the specification has met all Working Group requirements, or explain why the requirements have changed or been deferred."

See the SPC Requirements Evaluation at Candidate Recommendation.

Dependencies

Process: "must document changes to dependencies during the development of the specification."

The Working Group Charter names groups for coordination. The Working Group has liaised on a regular basis with these:

  • Web Authentication WG
  • Web Payment Security IG, including both the FIDO Alliance and EMVCo (especially their 3-D Secure Working Group)
  • Various open banking API organizations: Open Banking UK, Berlin Group, and STET.

The WPWG has not found it necessary to liase with the Web Application Security WG or ISO TC 68. For that reason, in the proposed charter (2021), we removed the ISO TC 68 liaison.

Implementation

Standardized Payment Method Identifier

TODO: Update Payment Method Identifiers to include "secure-payment-confirmation".

Experience

Process: "must document how adequate implementation experience will be demonstrated"

  • Chrome implementation (MacOS, Windows; Android Canary, and anticipating release to stable this year).
  • Pilots (Stripe, Adyen/Airbnb, Modirum)

At the current time:

  • We expect to request to advance to Candidate Recommendation without a second implementation (permitted by W3C process).
  • We expect to remain in Candidate Recommendation until we have a second browser implementation.

Test Suite

Features at Risk

  • We currently have not identified any features at risk.

Wide Review

Process: "must show that the specification has received wide review."

The specification has been reviewed (at least) by:

  • W3C Horizontal Groups
  • Payment Service Providers (Adyen, Stripe, Modirum)
  • Other standards bodies (EMVCo)

In August 2022 we sent notice to horizontal groups that SPC is approaching Candidate Recommendation and solicited additional reviews.

General Issues

Before Version 1

TODO: Track remaining open issues not covered below under Wide Review.

After Version 1

Web Authentication Working Group

In addition, because SPC depends heavily on Web Authentication / FIDO, there have been many discussions about features and interoperability among WPSIG and the Web Authentication WG. Our goal is for SPC to remain aligned with Web Authentication and to move whatever functionality we can out of SPC into Web Authentication (see details in SPC: From browser cache to FIDO/WebAuthn integration).

Issues for ongoing discussion (not blocking v1 release)

Horizontal Reviews

Accessibility

  • APA concluded there was no need to review the specification.
  • Subsequently, Ian Jacobs raised an issue (127) on icon accessibility and sought APA review; APA indicated satisfaction.

Technical Architecture Group

  • The TAG conducted a positive review of SPC; see issue 675.

Privacy

  • A PING review resulted in a set of privacy-related issues. All were resolved to the satisfaction of PING except bullets following this one.
  • SPC issue 154 relates to the user's ability to override a relying parties desire for a credential to be usable both for login and payments. The Web Payments Working Group suggests that this issue is best handled either by Web Authentication, or via CTAP, or some combination.

Internationalization

  • The WPWG is aware of one internationalization issue (93) related to the ability to localize strings that are provided as input to the API and that are displayed in the user agent's transaction dialog.
  • We anticipate an ECMAScript-level solution in the long term. In the short term, we have proposed as a backwards-compatible solution for displayable strings: each one is defined as a union of String and a Localizable (WebIDL) structure. Whether the Working Group publishes the Localizable structure definition in SPC or the I18N WG publishes a standalone specification that may be referenced by various Working Groups has yet to be determined.
  • We are awaiting replies from the I18N Working Group (who are themselves consulting with the TAG and others).

TODO: Determine path in v1 related to localization (e.g,. in-spec solution or independent spec solution by reference)

Security

  • Issue 14 raised 7 September 2021; no responses so far.
Clone this wiki locally