-
Notifications
You must be signed in to change notification settings - Fork 40
SPC Requirements Evaluation at Candidate Recommendation
ianbjacobs edited this page Jun 21, 2022
·
3 revisions
As part of preparing to advance Secure Payment Confirmation to Candidate Recommendation, we evaluate here how the specification fulfills (or does not) our requirements. Questions? public-payments-wg@w3.org.
- It must be possible to determine through JavaScript feature detection whether a user agent supports SPC.
- Achieved via canMakePayment for the payment method identifier 'secure-payment-confirmation'.
- It must be possible to call SPC from a Web site.
- Because many checkout experiences are offered through iframes, it must be possible to call SPC from an iframe.
- Both registration and authentication are possible in iframes, including cross-origin iframes.
- SPC usage within an iframe must be enabled through a permission policy.
- It must be possible to do an SPC Registration outside of a transaction.
- It must be possible to do an SPC Registration following a prior (non-SPC) authentication during a transaction. This registration should not prevent timely completion of the transaction.
- It is not a requirement that the relying party be able to do an SPC Registration in a third-party context. However, it could improve common payment flows if the relying party could register from a cross-origin iframe.
- SPC supports registration from a cross-origin iframe.
- The Relying Party must not be required to provide definitive information about a specific instrument at registration time. In other words, the API supports dynamic binding to a specific instrument at authentication time. This feature renders unnecessary additional functionality to update browser-stored instrument information.
- SPC registration uses a payment extension that includes an instrument member that is only used at authentication, not registration.
- It is not a requirement that instrument information be stored in the browser as part of an SPC Registration.
- SPC does not require instrument information to be stored in the browser at registration.
- The protocol should support multiple ways of accessing the instrument display information, including browser storage and authenticator storage.
- Instrument display information is passed as input to the API at authentication time.
- Each browser should natively support an SPC Registration user experience.
- The user agent should require and consume at least one transient user activation in order to display an SPC registration user experience.
- SPC consumes a transient user activation at registration.
- The party that invokes SPC registration must be able to specify a timeout for the registration user experience.
- The SecurePaymentConfirmationRequest dictionary includes a timeout member.
- Any origin (including the Relying Party) must be able to invoke SPC payment confirmation with the credential id(s) of the Relying Party.
- This is one of the ways that SPC differs from Web Authentication.
- Instrument information (e.g., a display string and icon) must be available for use within the payment confirmation user experience.
- Instrument information (display strings and icon) is passed to the API at authentication time and is displayed by the transaction dialog.
- The API must support accessibility and internationalization requirements associated with this information.
- The APA WG has confirmed accessible support for icon information provided to the API.
- See issue 93.
- The party that calls the API must be able to provide instrument information as input. Note: The Relying Party is the authoritative source of instrument information. If another party provides conflicting instrument information as input to the API, the Relying Party can detect this during subsequent validation.
- Instrument information (display strings and icon) is passed to the API at authentication time and is displayed by the transaction dialog.
- Each browser must natively support a payment confirmation user experience.
- The user agent must require and consume at least one transient user activation in order to display an SPC user experience.
- TO VERIFY
- Although we anticipate that in most cases the browser will render the payment confirmation user experience, the protocol should support rendering by other entities (e.g., the operating system or authenticator or for out-of-band authentication). Note: This feature would address use cases that require particularly secure display of information.
- The API does not constrain how and whether underlying authenticators display information passed to them.
- The payment confirmation user experience must display instrument information such as label and icon.
- The payment confirmation user experience must display amount and currency of the payment.
- The party that invokes SPC must be able to specify a timeout for the payment confirmation user experience. See issue 67.
- The payment confirmation user experience must include the origin of the top level where the API is called.
- The API supports both payeeName and/or payeeOrigin and the transaction dialog displays whatever is provided.
- The API must support payment confirmation with two factor authentication (e.g., with FIDO user verification check).
- SPC relies on Web Authentication for that functionality.
- The API should support payment confirmation with one factor authentication with user presence check.
- SPC relies on Web Authentication for that functionality.
- The API should support payment confirmation with one factor authentication (possession) without user presence check.
- SPC relies on Web Authentication for that functionality.
- If the user did an SPC Registration when using one instance of a browser, it should be possible to leverage that authentication from a different instance of the same browser (e.g., both browsers are Firefox)
- This is achieved via discoverable credentials. Furthermore, multi-device credentials may support sharing among browsers on different devices. *If the user did an SPC Registration when using one instance of a browser, it should be possible to leverage that authentication from any browser (e.g., one browser is Firefox and the other is Chrome). Note: Large Blob (WebAuthn Level 2) may be used to create portable stored data to reduce the total number of registrations.
- This is achieved via discoverable credentials (on the same device).
- It it left to the user agent how the user selects an authentication path when more than one matches the SPC Request. See issue 69 for discussion.
- When the user agent has no information matching the SPC Request, for privacy reasons the browser may inform the user that the API has been invoked but failed. Note: Whoever might call the API can determine in advance that the user has never done an SPC Registration, and choose not to call the API.
- SPC normatively requires the implementation maintain authentication ceremony privacy and not leak this lack of matching credentials to the caller in the 4.1.4. Steps to check if a payment can be made
- The SPC Assertion must include at least: top level origin, caller origin, relying party origin (rpid), one-time challenge, instrument information, transaction amount and currency.
- The SPC Assertion must include a signature over that data (based on the associated authenticator). This signature may be validated by the Relying Party or any other party with the appropriate key.
- If the user agent stores SPC Credential Identifiers (and any associated information), the user must be able to remove individual SPC Credential Identifiers from the user agent.
-
SPC Credential Identifiers must be origin-bound. All SPC Credential Identifiers on the same origin are expected be distinct.
- SPC relies on Web Authentication for this functionality.
- The API should allow relying parties to reduce the risk of cross-site tracking that might arise through the reuse of SPC Credential Identifiers. See issue 77.
- The Working Group discussed this issue with PING but could not come up with a practical obfuscation mechanism. The SPC specification does include guidance to help avoid joining different payment instruments.
- FIDO credentials should be usable for SPC activities and vice-versa, but the user agent must clearly communicate to the user how credentials are being used.
- See issue 157 for how the WPWG is working with the FIDO CTAP group on a bit to identify cross-origin enabled credentials.
- The API should not make it impossible for the user to communicate to the relying party to forget SPC Credential Identifiers. This might happen in a variety of ways (e.g., forget this authenticator and all associated instruments; forget any authenticators associated with this instrument, etc.). See issue 172.
- It must be possible to call SPC from a payment handler.
- Due to the initial implementation via Payment Request API, it is not possible to call SPC from a payment handler. However, there are very few deployed payment handlers, so the priority of this requirement is very low.
- It must be possible to do an SPC Registration from a payment handler.
- See note above on payment handlers.
- The payment confirmation user experience should include the title and favicon of the page where it was called. See issue 48 on merchant information display.
- The API might at some point support payment confirmation with one factor authentication (possession) but without a visible dialog and without a user presence check.
- The API should allow the relying party to express a preference for any of the supported levels of user interaction.
- For each transaction, a merchant should be able to express to the relying party a preference to use (or not use) any of the supported levels of user interaction.
- If the browser supports any relying party option less secure than two-factor, the browser must support a user preference to override that option and maintain two-factor authentication.
- If different user journeys are possible for a given authenticator (e.g., a low friction option), the SPC Assertion must also include information about the user's journey. This information may be part of the authenticator's own assertion. For example, the assertion must indicate whether the user completed the transaction without a user presence check.