You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What follows is an alternative flow and API design for SPC that enables a zero-friction flow where the payment network supports this.
Thanks to Gerhard for the idea of using the PReq in this way.
Advantages:
Support for zero-friction flow if RP decides that full WebAuthn flow is not needed
No fingerprinting by RP without explicit RP UI shown to user
Strong privacy model (No data returned to merchant until payment is completed by user)
Can be used with existing 3DS 2.0 backend messages and flows
Secure Payment Confirmation is not invoked by any origin except the RP
No need for browser to maintain instrument to credential mapping
Simpler DX with clear separation of concerns between payment instruments (used to identify a payment account) and credentials (used to identify a user)
Flow without instrument selection
e.g 3DS 2 with legacy card entry form
User provides details of payment instrument (e.g. card details)
Merchant contacts RP to get a URL for the RP payment method manifest
Merchant calls Payment Request using RP URL as payment method
Browser checks for Payment Handler that supports RP payment method and installs JIT if necessary
Browser invokes Payment Handler and passes it details of payment instrument provided by merchant.
Payment Handler does risk assessment on the transaction and if necessary (i.e. zero-friction not possible) gets a list of credential IDs and a challenge to do SPC. (Note: PH is executed in a 1st party context and has access to cookies and local storage in the RP domain. i.e. Good chance that zero-friction is possible despite no fingerprinting)
If zero-friction is possible return response to merchant and merchant completes the payment via the network.
If SPC is required AND there are credential IDs to use the Payment Handler invokes SPC providing the browser with the list of credential IDs and the challenge.
The resulting assertion is returned to the merchant
If the SPC fails the PH calls e.openWindow to render the fallback step-up authentication UI (e.g. SMS-based OTP or similar)
Flow with instrument selection
e.g. 3DS 2 with browser-rendered instrument selection or Google Pay
User clicks pay button and merchant calls Payment Request using a supported network URL(s) as the payment method(s)
Browser checks for instruments installed via Payment Handlers that support provided network payment method(s) and prompt user to select one.
Browser invokes Payment Handler of chosen instrument and passes it details of payment instrument.
Payment Handler does risk assessment on the transaction and if necessary (i.e. zero-friction not possible) gets a list of credential IDs and a challenge to do SPC. (Note: PH is executed in a 1st party context and has access to cookies and local storage in the RP domain. i.e. Good chance that zero-friction is possible despite no fingerprinting)
If zero-friction is possible return response to merchant and merchant completes the payment via the network.
If SPC is required AND there are credential IDs to use the Payment Handler invokes SPC providing the browser with the list of credential IDs and the challenge.
The resulting assertion is returned to the merchant
If the SPC fails the PH calls e.openWindow to render the fallback step-up authentication UI (e.g. SMS-based OTP or similar)
Assumptions:
Each instrument added by an RP payment handler will support multiple payment methods. In the most common case this will include a payment method identifier that uses the origin of the RP and a payment method identifier of the network.
The Payment Method Identifier of the RP is used to invoke the RP Payment Handler directly when the user has already provided payment instrument details and the RP is known by the merchant.
The Payment Method Identifier of the network is used to invoke any RP Payment Handler that supports that method and has already installed an instrument in the browser (i.e. prompting the user to select the instrument and thereby invoking the Payment Handler)
Example using existing 3DS 2 back-end flows
Alice enters the PAN of her Bank of America VISA card into a merchant website
Using the BIN of her PAN the merchant performs a PReq and gets back the following 3DS Method URLhttps://bankofamerica.com/web-payments/visa-platinum
NOTE: In a standard 3DS 2 flow the merchant is expected to render an iframe using this URL and the ACS uses this to fingerprint the user's browser. The data collected by the ACS is associated with a threeDSServerTransID generated by the merchant.
The merchant calls Payment Request API using the 3DS Method URL as the payment method identifier and passing Alice's PAN and the 3DS Server Transaction ID it generated in the request.
The browser will install the Payment Handler that is defined by the app manifest at https://bankofamerica.com/web-payments/webappmanifest.json
If the JIT install fails the PR API will return an error and the merchant falls back to legacy 3DS
If the payment handler was previously installed or the browser has visited this origin before the PH it will have access to cookies, local storage and WebCrypto APIs to perform some zero-friction checks such as verifying that this is the same device used previously. In Alice's case, she has visited the BofA website in this browser and completed a previous legacy 3DS checkout so she has cookies from bankofamerica.com that are read by the PH. The PH goes online to ACS to get a risk score for the transaction passing the transaction details, PAN and 3DS Server Transaction ID. The request will carry all of the previously installed cookies.
NOTE: The PH is not able to do fingerprinting without calling e.openWindow and showing the user some UI.
NOTE: Other means of doing client-side user identification are possible given the context. e.g. The PH could use local storage or the WebCrypto APIs to securely identify the user without the need for WebAuthn at this stage.
Since the purchase is of a high-value the ACS requests that SPC be used if available and returns a list of credentials that it knows have been enrolled by Alice on her various devices. The PH invokes SPC.
if(acsResponse.result==="SKIP-AUTHN"){e.respondWith(acsResponse)return}if(acsResponse.result==="DO-SPC"){const{challenge, allowCredentials}=spc// Internally the browser turns this into a WebAuthn get assertion callconstassertion=awaite.securePaymentConfirmation({instrumentId: result.instrument.key,
challenge,
allowCredentials,60000})if(assertion){e.respondWith(assertion)return}}
If SPC is not possible (e.g. no credentials returned or available) the PH invokes a legacy authN flow
You wrote above "No fingerprinting by RP without explicit RP UI shown to user." You refer to e.openWindow only in the final step of "Flow without instrument selection." I assume that means that other risk assessment would happen without the user having to see a window. So what is the explicit RP UI shown to the user? Thanks!
What follows is an alternative flow and API design for SPC that enables a zero-friction flow where the payment network supports this.
Thanks to Gerhard for the idea of using the PReq in this way.
Advantages:
Flow without instrument selection
e.g 3DS 2 with legacy card entry form
e.openWindow
to render the fallback step-up authentication UI (e.g. SMS-based OTP or similar)Flow with instrument selection
e.g. 3DS 2 with browser-rendered instrument selection or Google Pay
e.openWindow
to render the fallback step-up authentication UI (e.g. SMS-based OTP or similar)Assumptions:
Example using existing 3DS 2 back-end flows
https://bankofamerica.com/web-payments/visa-platinum
PaymentRequestEvent
otherwise the JIT install steps are followed first:And the server would then respond:
The browser will install the Payment Handler that is defined by the app manifest at
https://bankofamerica.com/web-payments/webappmanifest.json
If the JIT install fails the PR API will return an error and the merchant falls back to legacy 3DS
The text was updated successfully, but these errors were encountered: