├── 3ds-flows.png ├── 3ds-reqs.md ├── README.md ├── risk-assessment.png ├── spc-general.png ├── spc-general.puml ├── spc-psd2.md └── w3c.json /3ds-flows.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/w3c/wpsig/c90f812d63fd251d86a863dffc8a061d89a195f3/3ds-flows.png -------------------------------------------------------------------------------- /3ds-reqs.md: -------------------------------------------------------------------------------- 1 | # EMV® 3-D Secure Requirements for Risk Assessment 2 | 3 | The EMV® 3-D Secure Protocol (hereafter, "EMV 3DS") describes a 4 | "frictionless flow." The “frictionless” flow involves risk assessment 5 | by the issuing bank (or its Access Control Server partner) without 6 | requiring a user gesture. On the Web, this is generally accomplished 7 | by collecting device information (via JavaScript) during checkout and 8 | looking for stability in the device information across transactions. 9 | 10 | As changing browser behaviors alter the device information landscape, 11 | the [Web Payment Security Interest 12 | Group](https://www.w3.org/securepay/) is holding discussions about 13 | what emerging browser capabilities could help fulfill risk assessment 14 | requirements and privacy requirements. 15 | 16 | This document is a requirements document to support those discussions. 17 | 18 | Editors: 19 | 20 | * [Ian Jacobs](mailto:ij@w3.org) 21 | * Richard Ledain 22 | * Sameer Tare 23 | 24 | Status: This is a draft and represents no consensus. 25 | 26 | ## Background 27 | 28 | EMV® 3-D Secure helps prevent the unauthorized use of a card online and provides consumers and merchants with the confidence that they are protected from fraud, while also supporting an easy and convenient purchasing experience that reduces the number of declined transactions. 29 | 30 | EMV 3DS is a fraud-prevention technology that enables consumers to authenticate themselves with their card issuer. EMV 3DS supports intelligent, data-driven and risk-based decisioning that encourages frictionless authentication. This means that for most transactions, the consumer clicks or taps online and the payment is approved. 31 | 32 | For transactions that are higher risk, EMV 3DS provides an additional layer of security to validate that the individual making the purchase is the legitimate cardholder. 33 | 34 | Examples of high risk transactions include 35 | 36 | * Transactions made from a new device 37 | * Transactions made for an unusually large amount 38 | * Unexpected transaction types 39 | 40 | ## How does authentication work with EMV 3DS? 41 | 42 | * **Consumer**. Consumer uses a payment card to make an online purchase on a mobile phone, tablet, laptop or other device. 43 | * **Merchant**. To confirm that the consumer making the purchase is the actual cardholder, the merchant uses EMV 3DS for authentication. This involves sending data about the transaction, payment method and device information to the issuer. 44 | * **Issuer**. Issuer reviews the data and performs a Risk Assessment. For transactions considered low risk, the Issuer may decide to complete the transaction as frictionless which essentially means that the data collected for this transaction was sufficient to let the transaction proceed without any explicit user credential verification. For transactions that are higher risk, EMV 3DS provides an additional layer of security by validating that the individual making the purchase is the legitimate cardholder. In these cases, the issuer can choose to prompt the consumer to authenticate themselves using a one-time-passcode, knowledge-based questions, biometrics or other method. It’s important to note that Issuers in most cases already receive this data and are bound by the local regulations on how to process this data. 45 | 46 | ### EMV 3DS Risk Assessment 47 | 48 | ![Sources of data in EMV 3DS risk assessment](risk-assessment.png) 49 | 50 | ### EMV 3DS flows 51 | 52 | ![EMV 3DS flows](3ds-flows.png) 53 | 54 | * **Start**: Cardholder—The Cardholder initiates the transaction using a browser on a Consumer Device using a website operated by the 3DS Requestor. 55 | * **1.1**: 3DS Requestor and 3DS Server—The 3DS Requestor communicates with the 3DS Server. The 3DS Server determines the ACS and DS Protocol Version(s) and, if present obtains the 3DS Method URL for the requested card range and returns the information to the 3DS Requestor. The ACS and DS Protocol Version(s) and 3DS Method URL data were previously received by the 3DS Server via a PRes message. 56 | * **1.2**: 3DS Method on the 3DS Requestor checkout page—The 3DS Requestor checkout page loads the 3DS Method URL, if present, which allows the ACS to obtain additional browser information for risk-based decisioning. 57 | * **1.3**: 3DS Requestor and 3DS Server—The 3DS Requestor provides the necessary 3-D Secure information for the transaction to the 3DS Server. 58 | * **4**: 3DS Server and 3DS Requestor—The 3DS Server communicates the result of the ARes message to the 3DS Requestor and completes the transaction. The 3DS Integrator determines how the interaction between these components is implemented. 59 | 60 | ## The Question 61 | 62 | Is this the same device the user has been associated with? 63 | 64 | ### The Answer (Devices supporting SDKs) 65 | 66 | For transactions taking place on devices/platforms that support SDKs, the device identification is fairly structured and enables the issuer/ACS to leverage multiple identifiers to associate a device with the user. The device info parameters have been defined for following operating systems/platforms 67 | 68 | * Android 69 | * iOS 70 | * Windows 10 71 | * Platform Device Data 72 | 73 | ### The Answer (Browser) 74 | 75 | Data related to the browser being used to perform EMV 3DS transactions is collected via 2 channels 76 | 77 | * **3DSMethod** – This is a mechanism for the issuer/ACS to obtain additional browser data prior to authentication request flow. This browser data in addition to the other information available to the ACS/Issuer through authentication flow aids in the transaction risk assessment and associated decision on completing the transaction as frictionless or asking for additional user credentials through a step-up/challenge. 3DSMethod is a javascript executed on the browser and is owned and maintained by the Issuer/ACS and it is made available to the browser through a trusted party in the EMV 3DS Flow called as 3DS Server. The data collected by this method is proprietary to each issuer/ACS as determined by their risk engines. 78 | * **Browser Data in Authentication Request (AReq)**. This is the mechanism by which a list of browser data is carried through the EMV 3DS AReq data elements. This information in addition to the data issuer/ACS might have collected as part of 3DSMethod execution allows for intelligent risk-based decisions along with the optimization of the user experience. The data collected as part of this method is defined by the EMV 3DS Specification and is as follows: Accept Headers, IP Address, Java Enable, JavaScript Enabled, Language, Screen Color Depth, Screen Height and Width, Time Zone, and User-Agent string. 79 | 80 | 81 | ## Problem Statement 82 | 83 | * Issuers rely on a combination of existing identifiers to identify the device 84 | * These identifiers could be originally intended to be used for other purposes and are likely to change in future 85 | * Privacy controls on the browser data inadvertently impact browser data for risk assessment which can result in more challenges for users during transactions 86 | * There are no unique identifiers defined for Transaction Risk Assessment 87 | * As the issuers interact with cardholder through iframe in merchant webpage, using cookies is not a viable approach 88 | * There is lack of hardware based, immutable identifiers that could be derived from browsers for use in Risk Assessment 89 | 90 | ## Finding a Solution 91 | 92 | Device recognition is and will remain a critical need for Transaction Risk Assessments in all Card Not Present (CNP) Transactions. The following statement describes the ideal solution at a high level that is desired to be achieved as a result of this collaboration: **Find a way to identify a browser in a unique, privacy aligned manner to be used exclusively for Transaction Risk Assessment in a payment context.** 93 | 94 | ### Goals 95 | 96 | * Enable new identifiers/identification mechanism are generated and protected by browser core libraries 97 | * Enable the new identifiers/identification mechanism to be accessed/used only in payment context 98 | * Ensure the new identifiers/identification mechanism are in alignment with W3C/PING road-map 99 | * Ensure any required user actions do not interrupt the user experience during payments flow 100 | 101 | Furthermore, the ideal solution will not: 102 | 103 | * Enable tracking of users outside of a payment context 104 | * Enable creation of a super-cookie used for all sorts of device recognition 105 | * Result in more friction through user gestures/interactions than present today 106 | 107 | ### Requirements 108 | 109 | * These identifiers will be unique for each browser instance 110 | * These identifiers will be generated and protected by browser core libraries and will be generated through native API calls 111 | * User will have option to reset the identifier, upon resetting the user may see more friction (challenge in EMV 3DS context) until the new identifiers are part of issuer/ACS risk models 112 | * User enrollment/consent takes place outside of the payments context and does not interrupt the payment flow 113 | 114 | ## Acknowledgments 115 | 116 | EMV® is a registered trademark in the U.S. and other countries and an unregistered trademark elsewhere. The EMV trademark is owned by EMVCo, LLC. 117 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # wpsig 2 | Web Payment Security Interest Group 3 | 4 | Please see the [Projects](https://github.com/w3c/wpsig/projects) for work streams 5 | -------------------------------------------------------------------------------- /risk-assessment.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/w3c/wpsig/c90f812d63fd251d86a863dffc8a061d89a195f3/risk-assessment.png -------------------------------------------------------------------------------- /spc-general.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/w3c/wpsig/c90f812d63fd251d86a863dffc8a061d89a195f3/spc-general.png -------------------------------------------------------------------------------- /spc-general.puml: -------------------------------------------------------------------------------- 1 | @startuml 2 | 3 | autonumber 4 | hide footbox 5 | skinparam ParticipantPadding 20 6 | skinparam BoxPadding 10 7 | 8 | title General SPC Authentication Flow During Checkout 9 | 10 | actor Consumer as Consumer <> 11 | participant Merchant as Merchant <> 12 | 13 | box "Web Browser Environment" 14 | participant "Browser Rendering Engine" as Browser 15 | participant "Browser Native UX" as Native 16 | end box 17 | 18 | box "Authenticator Environment (Browser/OS)" 19 | participant "Authenticator" 20 | end box 21 | 22 | participant "Relying Party" as RP 23 | 24 | note over Authenticator 25 | Authenticator may be implemented in OS, Browser, 26 | external hardware, or combination. 27 | end note 28 | 29 | note over Merchant 30 | Merchant may use a PSP / PISP in this flow. 31 | end note 32 | note over RP 33 | The Relying Party may be a variety of parties, 34 | including the Issuing Bank/ASPSP, or a delegate 35 | (e.g., ACS), or the payment service provider/PISP, or 36 | another entity. We anticipate industry 37 | adoption speeds and use cases will lead to different 38 | configurations. 39 | end note 40 | Consumer->Merchant: Checkout Intent 41 | Merchant->Browser: Provide checkout experience 42 | Browser->Consumer: Render checkout experience 43 | Consumer->Merchant: Click Pay Button 44 | group Instrument selection 45 | Merchant->Browser: Provide instrument selection UX 46 | note over Merchant, Browser 47 | Examples: Web form, card on file 48 | end note 49 | Browser->Consumer: Render instrument selection UX 50 | Consumer->Merchant: Select instrument 51 | end group 52 | group Authentication 53 | Merchant->RP: Request SPC Credentials associated with instrument 54 | note over RP 55 | RP has instrument / SPC Credential ID bindings after prior enrollment 56 | end note 57 | RP->Merchant: Return SPC Credentials (and possibly additional information for SPC call) 58 | note over Merchant, Browser 59 | If no SPC Credentials for instrument, merchant can authenticate differently 60 | end note 61 | Merchant->Browser: Call SPC 62 | note over Merchant, Browser 63 | Input: Amount, currency, payee info, SPC Credential IDs, instrument info, unique challenge 64 | end note 65 | note over Merchant, Browser 66 | Once SPC invoked, control leaves merchant environment; no opportunity to tamper with data. 67 | end note 68 | Native->Consumer: Prompt user to authenticate to pay and show dynamic linking data. 69 | note over Browser, Authenticator 70 | Browser may delegate display to authenticators for added security. 71 | end note 72 | Consumer->Native: Agree to authenticate 73 | Native->Authenticator: Request authentication 74 | Authenticator->Consumer: Prompt user to authenticate (e.g., biometric) 75 | Consumer->Authenticator: Authenticate 76 | alt#Gold #LightBlue Successful authentication 77 | Authenticator->Authenticator: Sign amount, currency, payee, instrument info, challenge 78 | note over Authenticator 79 | SPC Assertion constitutes authentication code mandated by RTS. Signed 80 | data is what user saw. Unchanged between display 81 | and cryptographic signature. 82 | end note 83 | Authenticator -> Browser: SPC Assertion with signature over data 84 | else #Pink Failure 85 | Authenticator -> Browser: Authentication Rejected 86 | end 87 | Browser->Merchant: Return authentication result 88 | Merchant->RP: Communicate authentication result for verification 89 | note over RP 90 | Relying Party is authoritative source of information and thus can 91 | verify that signed data displayed to the user matches 92 | what it knows on server (challenge, instrument info, etc.). 93 | end note 94 | RP->RP: Validation (using public key that is part of enrolled SPC Credential) 95 | Merchant<-RP: Verification result 96 | end group 97 | group Authorization 98 | Merchant->RP: Request authorization 99 | RP->Merchant: Authorization response 100 | end group 101 | Merchant-->Consumer: Checkout Completed 102 | 103 | @enduml 104 | -------------------------------------------------------------------------------- /spc-psd2.md: -------------------------------------------------------------------------------- 1 | # Using SPC to fulfill PSD2 Requirements for SCA and Dynamic Linking 2 | 3 | Status: This is a draft document without consensus. The Editor hopes that the Web Payment Security Interest Group will develop this document and publish an Interest Group Note. 4 | 5 | Note: This document has not been updated in light of the evolution of passkeys. 6 | 7 | Questions? Ian Jacobs <ij@w3.org>. 8 | 9 | [Secure Payment Confirmation 10 | (SPC)](https://github.com/w3c/secure-payment-confirmation) is a new (draft) 11 | Web API to support streamlined authentication during a payment 12 | transaction. In this document we explain how SPC can be used to 13 | fulfill the Strong Customer Authentication (SCA) and Dynamic Linking 14 | requirements of Payment Services Directrive (PSD2). 15 | 16 | Note: In this document we assume that SPC leverages FIDO Authentication. We therefore recommend familiarity with FIDO Authentication and specifically the Web Authentication specification. 17 | 18 | ## Background 19 | 20 | SPC is being designed for use within a wide range of payment methods 21 | (cards, open banking, proprietary payment methods, etc.) and within a 22 | variety of authentication protocols (including, but not limited to, 23 | EMV® 3-D Secure). W3C is working closely with the FIDO Alliance, 24 | EMVCo, and other partners to achieve a number of benefits through SPC: 25 | 26 | * **Authentication Streamlined for Payment**. We expect SPC to build on the FIDO authentication experience in several ways, by further accelerating authentication (compared to one-time passcodes), requiring fewer user gestures, offering a predictable user experience across sites, and avoiding redirects. 27 | * **Scalable and Ubiquitous**. SPC supports streamlined authentication across multiple merchant sites following a single enrollment. 28 | * **Simpler and more Secure Front-end Deployment**. The browser manages the display of the payment confirmation experience, removing the need for other parties (e.g., issuing banks or payment apps) to do so. In addition, enabling payment service providers or others to authenticate the user can reduce the need to embed code provided by a Relying Party in a Web page, reducing security risks. Reducing the need for redirects should also simplify solutions. 29 | * **Designed to Meet Regulatory Requirements**. The standardized payment confirmation user experience is designed to help entities fulfill regulatory requirements (e.g., strong customer authentication and dynamic linking under PSD2) and other customer authentication use cases. 30 | 31 | In this document we focus on the last point: how to use SPC to fulfill 32 | PDS2 requirements. 33 | 34 | ## Unique SPC Features 35 | 36 | The above benefits are grounded in a small number of unique features that distinguish SPC from FIDO authentication "out of the box": 37 | 38 | * **Browser-native UX for payment confirmation**. The browser (or secure hardware) provides a consistent and efficient authentication UX across merchant sites and relying parties. A browser-native user experience should modestly improve transaction security compared to ordinary Web content rendered in an iframe. 39 | * **Cryptographic evidence**. Payment confirmation generates cryptographic evidence of the user's confirmation of payment details. 40 | * **Third-Party Enrollment**. With FIDO, it is possible to authenticate from a cross-origin iframe, but one must register an authenticator in a first party context. With SPC, it is possible to register an authenticator from a cross-origin iframe, which is a common payment ecosystem use cases. 41 | * **Cross-origin authentication**. With FIDO, the Relying Party that creates FIDO credentials is the only origin that can generate an assertion with those credentials to authenticate the user. With SPC, any origin can generate an assertion during a transaction even by leveraging another Relying Party's credentials. 42 | 43 | These features are used to satisfied two key PSD2 requirements: 44 | 45 | * **Strong Customer Authentication (SCA)**: FIDO Authentication is used to fulfill the SCA requirement. SPC's cross-origin authentication reduces user experience friction by requiring fewer enrollments. 46 | * **Dynamic linking**: SPC adds to browsers built-in support for the display of dynamic linking data and cryptographic proof (via FIDO) of what data was displayed. 47 | 48 | ## General SPC Flow 49 | 50 | SPC consists of two phases: enrollment and authentication. The 51 | following flow diagram provides a general view of the parties involved 52 | in SPC Authentication. 53 | 54 | The flow diagram describes general roles. Each specific payment 55 | ecosystem or authentication protocol will determine which parties play 56 | which roles, including: 57 | 58 | * Account Provider (e.g., ASPSP, or issuing bank, or ACS with EMV® 3-D Secure, or SRC System with EMV® Secure Remote Commerce) 59 | * Payment Service Provider (e.g., PISP) 60 | * Merchant (see FAQ question below on delegation use case) 61 | 62 | The centrality of the Relying Party in a payment system has an impact on SPC's scalability. 63 | 64 | General SPC Flow Diagram; PUML source available 65 | 66 | ### SPC Integration into Backend Protocols 67 | 68 | As the flow diagram indicates, during authentication the merchant 69 | interacts with the Relying Party at two moments: 70 | 71 | * To request any SPC Credentials associated with an instrument, and 72 | * To provide an SPC Assertion for verification. 73 | 74 | This communication may take place using a variety of protocols. At the present time, for example, we are discussing SPC integration with EMV® 3-D Secure, EMV® Secure Remote Commerce, and [Open Banking](https://docs.google.com/document/d/1qjBPa6l0EM9A3sLl9neccq_8UPHe90jXTGXqcbge2vQ/edit). 75 | 76 | EMVCo has indicated that they anticipate that EMV® 3-D Secure version 77 | 2.3 will include support for SPC. For related information, see [How 78 | Does EMV® 3-D Secure Help to Meet European Regulation While Supporting 79 | the Global Fight Against CNP 80 | Fraud?](https://www.emvco.com/emv_insights_post/how-does-emv-3-d-secure-help-to-meet-european-regulation-while-supporting-the-global-fight-against-cnp-fraud/) 81 | 82 | ## Security Analysis 83 | 84 | SPC leverages FIDO Authentication and builds on FIDO security properties described in the [FIDO Security Reference](https://fidoalliance.org/specs/fido-v2.0-id-20180227/fido-security-ref-v2.0-id-20180227.html). The SPC analysis builds on and refers to that work. 85 | 86 | Note: 87 | 88 | * Bracketed labels such as "[SG-1]" are defined in the [FIDO Security Reference](https://fidoalliance.org/specs/fido-v2.0-id-20180227/fido-security-ref-v2.0-id-20180227.html). However, labels that begin with "SPC" are defined in this document. 89 | * See also: [FIDO Certification Program](https://fidoalliance.org/certification/) for information about certification of FIDO servers, clients, and authenticators. 90 | 91 | ### Security Goals 92 | 93 | SPC is especially concerned with the following security goals identified in the FIDO Security Reference: 94 | 95 | * [SG-1] Strong User Authentication: Authenticate (i.e., recognize) a user and/or a device to a relying party with high (cryptographic) strength. This is the goal most closely related to the [PSD2 SCA requirement](#psd2-sca). 96 | * [SG-14] Transaction Non-Repudiation: Provide strong cryptographic non-repudiation for secure transactions. This is the goal most closely related to the [PSD2 dynamic linking requirement](#psd2-dl). The SPC assertion is created upon positive user verification and thus represents the customer’s acknowledgement and consent of the transaction details. 97 | 98 | Note: 99 | 100 | * SPC focuses on user authentication. SPC may also help Relying Parties protect against other forms of fraud (e.g., fradulent merchants) but payments systems manage those risks through other mechanisms as well. 101 | 102 | ### Security Measures 103 | 104 | SPC builds on the Security Measures described in the FIDO Security Reference. This table maps SPC features to the most relevant FIDO security measures: 105 | 106 | | FIDO Security Measure | SPC Feature(s) | 107 | | --------------------- | ----------- | 108 | | [SM-5] User Consent | [browser-native UX for payment confirmation](#spc-ux) | 109 | | [SM-10] Transaction Confirmation | [browser-native UX for payment confirmation](#spc-ux); [cryptographic evidence](#spc-crypto-evidence) | 110 | | [SM-14] AppID Separation | [cross-origin authentication](#spc-cross-origin). SPC explicitly relaxes this constraint compared to FIDO. | 111 | 112 | ### Security Assumptions 113 | 114 | An SPC security analysis begins with a security analysis of the underlying 115 | FIDO system. The following assumptions identified in the FIDO Security Reference 116 | are particularly relevant as background to evaluating SPC: 117 | 118 | * [SA-1] The Authenticator and its cryptographic algorithms and parameters (key size, mode, output length, etc.) in use are not subject to unknown weaknesses that make them unfit for their purpose in encrypting, digitally signing, and authenticating messages. (Thus, the SPC Assertion resists tampering between when it leaves the browser and when the Relying Party verifies it and ensures it meets Relying Party expectations.) 119 | * [SA-3] Applications on the user device are able to establish secure channels that provide trustworthy server authentication, and confidentiality and integrity for messages (e.g., through TLS). 120 | * [SA-4] The computing environment on the FIDO user device and the and applications involved in a FIDO operation act as trustworthy agents of the user. 121 | * [SA-6] The computing resources at the Relying Party involved in processing a FIDO operation act as trustworthy agents of the Relying Party. 122 | 123 | In particular, we make the following assumptions specific to SPC: 124 | 125 | * [SPC-SA-1] Display integrity: Once SPC has been called, code running in the browser (e.g., in the JavaScript environment) cannot tamper with the display of transaction information by the browser. 126 | * [SPC-SA-2] Signing integrity: The transaction information displayed by the browser is the same information that is signed by the authenticator. 127 | 128 | ## Detailed Evaluation of PSD2 Requirements and SPC 129 | 130 | The PSD2 requirements below are drawn from [Regulatory Technical Standards on strong customer authentication and secure communication under PSD2 ](https://www.eba.europa.eu/sites/default/documents/files/documents/10180/1761863/314bd4d5-ccad-47f8-bb11-84933e863944/Final%20draft%20RTS%20on%20SCA%20and%20CSC%20under%20PSD2%20%28EBA-RTS-2017-02%29.pdf) (23 February 2017 edition). 131 | 132 | Note: This evaluation approach is based on [How FIDO Standards Meet PSD2’s Regulatory Technical Standards Requirements On Strong Customer Authentication](https://fidoalliance.org/how_fido_meets_the_rts_requirements/) from the FIDO Alliance. Below, this document is identified as "FIDO-PSD2". 133 | 134 | ### [RTS Chapter 1] General provisions 135 | 136 | #### [RTS Article 3] – Review of the Security Requirements 137 | 138 | | Article | Requirement | How SPC Meets It | 139 | | ----------- | ----------- | ----------- | 140 | | Article 3.1 | The implementation of the security measures referred to in Article 1 shall be documented, periodically tested, evaluated and audited in accordance with the applicable legal framework of the payment service provider by auditors with expertise in IT security and payments and operationally independent within or from the payment service provider | See FIDO-PSD2 for information about FIDO security certification. In addition, W3C provides publicly available tests for Web APIs to improve cross-browser interoperability. 141 | | Article 3.3 | The audit review shall evaluate and report on the compliance of the payment service provider’s security measures with the requirements set out in this Regulation. | See FIDO-PSD2 for information about FIDO security certification. W3C provides publicly available tests for Web APIs to improve cross-browser interoperability. | 142 | 143 | ### [RTS Chapter II] Security measures for the application of Strong Customer 144 | Authentication 145 | 146 | #### [RTS Article 4] – Authentication code 147 | 148 | | Article | Requirement | How SPC Meets It | 149 | | ----------- | ----------- | ----------- | 150 | | Article 4.1 | The authentication shall be based on two or more elements which are categorised as knowledge, possession and inherence and shall result in the generation of an authentication code | This is achieved via FIDO; see FIDO-PSD2. The SPC assertion constitutes the authentication code, and includes information displayed to the user; see dynamic linking below. 151 | | Article 4.2 | For the purpose of paragraph 1, payment service providers shall adopt security measures ensuring that each of the following requirements is met: (a) no information on any of the elements referred to in paragraph 1 can be derived from the disclosure of the authentication code; (b) it is not possible to generate a new authentication code based on the knowledge of any other authentication code previously generated; (c) the authentication code cannot be forged. | These are achieved via FIDO; see FIDO-PSD2. 152 | | Article 4.3 | Payment service providers shall ensure that the authentication by means of generating an authentication code includes each of the following measures: (a) where the authentication for remote access, remote electronic payments and any other actions through a remote channel which may imply a risk of payment fraud or other abuses has failed to generate an authentication code for the purposes of paragraph 1, it shall not be possible to identify which of the elements referred to in that paragraph was incorrect; (b) the number of failed authentication attempts that can take place consecutively, after which the actions referred to in Article 97(1) of Directive (EU) 2015/2366 shall be temporarily or permanently blocked, shall not exceed five within a given period of time; (c) the communication sessions are protected against the capture of authentication data transmitted during the authentication and against manipulation by unauthorised parties in accordance with the requirements in Chapter V; (d) the maximum time without activity by the payer after being authenticated for accessing its payment account online shall not exceed 5 minutes. | Most of these are achieved via FIDO; see FIDO-PSD2. For additional information on timeouts in SPC, see [issue 67](https://github.com/w3c/secure-payment-confirmation/issues/67). 153 | 154 | #### [RTS Article 5] – Dynamic linking 155 | 156 | | Article | Requirement | How SPC Meets It | 157 | | ----------- | ----------- | ----------- | 158 | | Article 5.1 | Where payment service providers apply strong customer authentication in accordance with Article 97(2) of Directive (EU) 2015/2366, in addition to the requirements of Article 4 of this Regulation, they shall also adopt security measures that meet each of the following requirements: (a) the payer is made aware of the amount of the payment transaction and of the payee; (b) the authentication code generated is specific to the amount of the payment transaction and the payee agreed to by the payer when initiating the transaction; (c) the authentication code accepted by the payment service provider corresponds to the original specific amount of the payment transaction and to the identity of the payee agreed to by the payer; (d) any change to the amount or the payee results in the invalidation of the authentication code generated. | Implementations of SPC include the secure display of the information required by 5.1.a. The SPC assertion includes a signature over a hash of transaction specific information (thus, amount and payee information) as well as a relying-party provided challenge; this fulfills 5.1.b. To fulfill 5.1.c and 5.1.d, the Relying Party needs to be made aware of the transaction amount and payee identity prior to the invocation of SPC; we anticipate this will be addressed via protocols such as EMV® 3-D Secure. Once SPC authentication has taken place, the Relying Party can use the (FIDO) public key generated during enrollment to validate the SPC assertion. If the signed data matches the Relying Parties expectations, the Relying Party is assured that the SPC implementation presented this data to user who then signed it with the user's Authenticator. 159 | | Article 5.2 | For the purpose of paragraph 1, payment service providers shall adopt security measures which ensure the confidentiality, authenticity and integrity of each of the following: (a) the amount of the transaction and the payee throughout all of the phases of the authentication; (b) the information displayed to the payer throughout all of the phases of the authentication including the generation, transmission and use of the authentication code | SPC is a JavaScript API supported by the browser, which represents the user. Thus, for the purposes of 5.2.a and 5.2.b, calling SPC does not itself expose information to any other parties. For information about protections once the browser invokes FIDO authentication, see FIDO-PSD2. For the authenticity and integrity requirements, the SPC implementation displays information that it was provided as input. Once the SPC implementation displays native user experience, the information can no longer be tampered with in the merchant environment. Finally, the relying party retains the authoritative information about the transaction and enrolled instrument, and thus can validate the authentication results to ensure the authenticity and integrity of the data. 160 | | Articles 6/7/8 | 1. Payment service providers shall adopt measures to mitigate the risk that the elements of strong customer authentication categorised as knowledge/possession/ inherence are uncovered by, or used by or disclosed to, unauthorised parties. 2. The use by the payer of those elements shall be subject to mitigation measures in order to prevent their disclosure to unauthorised parties or their replication or their unauthorised use. 3. Payment service providers shall ensure that access devices and software that read authentication elements categorised as inherence have a very low probability of an unauthorised party being authenticated as the payer. | This is achieved via FIDO; see FIDO-PSD2. 161 | | Article 9 (1) | Payment service providers shall ensure that the use of the elements of strong customer authentication referred to in Articles 6, 7 and 8 is subject to measures which ensure that, in terms of technology, algorithms and parameters, the breach of one of the elements does not compromise the reliability of the other elements. | This is achieved via FIDO; see FIDO-PSD2. 162 | | Articles 9.2 & 9.3 | Payment service providers shall adopt security measures, where any of the elements of strong customer authentication or the authentication code itself is used through a multi-purpose device, to mitigate the risk which would result from that multi-purpose device being compromised. For the purposes of paragraph 2, the mitigating measures shall include each of the following: (a) the use of separated secure execution environments through the software installed inside the multi-purpose device; (b) mechanisms to ensure that the software or device has not been altered by the payer or by a third party; (c) where alterations have taken place, mechanisms to mitigate the consequences thereof. | This is achieved via FIDO; see FIDO-PSD2. 163 | 164 | ### [RTS Chapter IV] Confidentiality and integrity of the Payment Service User’s security credentials 165 | 166 | #### [RTS Article 22] – General Requirements 167 | 168 | | Article | Requirement | How SPC Meets It | 169 | | ----------- | ----------- | ----------- | 170 | | Articles 22.1 & 22.2 | Payment service providers shall ensure the confidentiality and integrity of the personalised security credentials of the payment service user, including authentication codes, during all phases of the authentication. 2. For the purpose of paragraph 1, payment service providers shall ensure that each of the following requirements is met: (a) personalised security credentials are masked when displayed and are not readable in their full extent when input by the payment service user during the authentication; (b) personalised security credentials in data format, as well as cryptographic materials related to the encryption of the personalised security credentials are not stored in plain text; (c) secret cryptographic material is protected from unauthorised disclosure. | This is primarily achieved via FIDO; see FIDO-PSD2. Note that the SPC authentication confirmation dialog displays whatever is input by the caller. Thus, the caller should provide just enough instrument information for user recognition of the instrument. 171 | | Article 22.3 | Payment service providers shall fully document the process related to the management of cryptographic material used to encrypt or otherwise render unreadable the personalised security credentials. | This is achieved via FIDO; see FIDO-PSD2. 172 | | Article 22.4 | Payment service providers shall ensure that the processing and routing of personalised security credentials and of the authentication codes generated in accordance with Chapter II take place in secure environments in accordance with strong and widely recognised industry standards. | This is achieved via FIDO; see FIDO-PSD2. 173 | 174 | #### [RTS Article 23] – Creation and transmission of credentials 175 | 176 | | Article | Requirement | How SPC Meets It | 177 | | ----------- | ----------- | ----------- | 178 | | Article 23 | Payment service providers shall ensure that the creation of personalised security credentials is performed in a secure environment. They shall mitigate the risks of unauthorised use of the personalised security credentials and of the authentication devices and software following their loss, theft or copying before their delivery to the payer. | This is achieved via FIDO; see FIDO-PSD2. 179 | 180 | #### [RTS Article 24] – Association with the payment service user 181 | 182 | | Article | Requirement | How SPC Meets It | 183 | | ----------- | ----------- | ----------- | 184 | | Articles 24.1 & 24.2 | 1. Payment service providers shall ensure that only the payment service user is associated, in a secure manner, with the personalised security credentials, the authentication devices and the software. 2. For the purpose of paragraph 1, payment service providers shall ensure that each of the following requirements is met: (a) the association of the payment service user’s identity with personalised security credentials, authentication devices and software is carried out in secure environments under the payment service provider’s responsibility comprising at least the payment service provider’s premises, the internet environment provided by the payment service provider or other similar secure websites used by the payment service provider and its automated teller machine services, and taking into account risks associated with devices and underlying components used during the association process that are not under the responsibility of the payment service provider; (b) the association by means of a remote channel of the payment service user’s identity with the personalised security credentials and with authentication devices or software is performed using strong customer authentication. | See FIDO-PSD2 for the parts of this requirement addressed by FIDO; SPC does not add to this. 185 | 186 | #### [RTS Article 25] – Delivery of credentials, authentication devices and software 187 | 188 | | Article | Requirement | How SPC Meets It | 189 | | ----------- | ----------- | ----------- | 190 | | Articles 25.1 & 25.2 | 1. Payment service providers shall ensure that the delivery of personalised security credentials, authentication devices and software to the payment service user is carried out in a secure manner designed to address the risks related to their unauthorised use due to their loss, theft or copying. 2. For the purpose of paragraph 1, payment service providers shall at least apply each of the following measures: (a) effective and secure delivery mechanisms ensuring that the personalized security credentials, authentication devices and software are delivered to the legitimate payment service user; (b) mechanisms that allow the payment service provider to verify the authenticity of the authentication software delivered to the payment services user by means of the internet; (c) arrangements ensuring that, where the delivery of personalised security credentials is executed outside the premises of the payment service provider or through a remote channel: (i) no unauthorised party can obtain more than one feature of the personalised security credentials, the authentication devices or software when delivered through the same channel; (ii) the delivered personalised security credentials, authentication devices or software require activation before usage; (d) arrangements ensuring that, in cases where the personalised security credentials, the authentication devices or software have to be activated before their first use, the activation shall take place in a secure environment in accordance with the association procedures referred to in Article 24. | This is achieved via FIDO; see FIDO-PSD2. 191 | 192 | #### [RTS Article 26] – Renewal of personalized security credentials 193 | 194 | | Article | Requirement | How SPC Meets It | 195 | | ----------- | ----------- | ----------- | 196 | | Article 26 | Payment service providers shall ensure that the renewal or reactivation of personalized security credentials adhere to the procedures for the creation, association and delivery of the credentials and of the authentication devices in accordance with Articles 23, 24 and 25. | This is achieved via FIDO; see FIDO-PSD2. 197 | 198 | #### [RTS Article 27] – Destruction, deactivation and revocation 199 | 200 | | Article | Requirement | How SPC Meets It | 201 | | ----------- | ----------- | ----------- | 202 | | Article 27 | Payment service providers shall ensure that they have effective processes in place to apply each of the following security measures: (a) the secure destruction, deactivation or revocation of the personalised security credentials, authentication devices and software; (b) where the payment service provider distributes reusable authentication devices and software, the secure re-use of a device or software is established, documented and implemented before making it available to another payment services user; (c) the deactivation or revocation of information related to personalised security credentials stored in the payment service provider’s systems and databases and, where relevant, in public repositories. | This is achieved via FIDO; see FIDO-PSD2. In addition, for any information stored in the browser related to an SPC implementation, browsers provide tools for lifecycle management (including deletion) of credentials. 203 | 204 | ## FAQ 205 | 206 | ### Can SPC be used with delegated authentication? 207 | 208 | [As mentioned above](#scale), one design goal of SPC is to scale across 209 | merchants. The general SPC flow emphasizes this point: the user 210 | enrolls for SPC authentication once (e.g., with the issuing bank) and 211 | can then authenticate on any merchant site without re-enrolling. 212 | 213 | SPC can also be used in "delegated authentication" use cases, where 214 | the merchant (or their payment service provider) is the Relying 215 | Party. When the merchant or payment service provider, is the Relying 216 | Party: 217 | 218 | * The "native browser UX" and "cryptographic evidence" benefits of SPC 219 | remain relevant, but there is likely to be less "scalability across 220 | merchants." 221 | 222 | * Other parties in the payment ecosystem (e.g., the ACS in EMV® 3-D 223 | Secure) may not be in a position to directly validate the 224 | authentication results, but the authentication may still be useful 225 | as part of a risk assessment strategy. As an example of such a 226 | strategy, see [Technical Note: FIDO Authentication and EMV 3-D 227 | Secure – Using FIDO for Payment 228 | Authentication](https://fidoalliance.org/technical-note-fido-authentication-and-emv-3-d-secure-using-fido-for-payment-authentication/) by the FIDO Alliance and [Use of FIDO Data in 3-D Secure Messages](https://www.emvco.com/wp-content/uploads/documents/EMVCo_3DS_FIDOData-WPv1.0_20200710.pdf) by EMVCo. 229 | 230 | ### How can one test and evaluate an SPC-based solution (in light of Article 3)? 231 | 232 | An SPC-based solution consists of the following components: 233 | 234 | * The FIDO Authenticator 235 | * The browser 236 | * The PSP application/environment 237 | * The means used to exchange credentials and assertions (e.g., via EMV® 3-D 238 | Secure or a different protocol or proprietary channels). 239 | * The network connection 240 | 241 | Independent labs can evaluate the code, documentation, test suites, third-party tools, and certification processes associated with these components. For FIDO authenticators, please see the [FIDO Alliance's certification process](https://fidoalliance.org/certification/). 242 | 243 | For the browser component specifically, we recommend the following: 244 | 245 | * Start with specifications for specific features, including [Secure Payment Confirmation](https://w3c.github.io/secure-payment-confirmation/), [Web Authentication](https://w3c.github.io/webauthn/), and [Client to Authenticator Protocol (CTAP)](https://fidoalliance.org/specifications/download/). The specifications are important to understanding which aspects of underlying code are relevant to a security evaluation. Specifications generally include "Security Considerations" sections. 246 | * The W3C community develops [publicly available test suites](http://web-platform-tests.org/) to promote interoperable and correct implementations of its specifications. Independent labs may validate expected browser behavior using these test suites. 247 | * To evaluate an individual browser, we recommend contacting the browser vendor and locating testing and good practices resources the vendor may provide for this purpose. In most cases, browser engine code is available as an open source project that can evaluated independently. 248 | 249 | Regarding the integrity and security of SPC communications, please note 250 | the following: 251 | 252 | * The Relying Party remains the authoritative source of information 253 | about the user's payment instruments and authentication credentials. A 254 | Relying Party can detect bad data upon verification of an SPC 255 | credential and refuse to authorize a transaction. 256 | * Because browsers are used for significant sensitive and high-value 257 | commercial activity, there is substantial and adversarial testing of 258 | browser security. End-users can more easily trust their browser than 259 | they can trust or assess the security of multiple third-party 260 | applications. Furthermore, the browser can help protect both users and 261 | those with whom they do business from risks of spoofing and 262 | compromise. For example, SPC moves the display of transaction 263 | information into a more trusted environment than code running in the 264 | browser (see [SPC-SA-1](#spc-sa-1) and [SPC-SA-2](#spc-sa-2)), to help 265 | reduce the risk of spoofing. 266 | -------------------------------------------------------------------------------- /w3c.json: -------------------------------------------------------------------------------- 1 | { 2 | "group": ["113649"], 3 | "contacts": ["ianbjacobs"], 4 | "repo-type": "article" 5 | } 6 | --------------------------------------------------------------------------------