This application claims the benefit of, and priority to, U.S. Patent Application No. 16/266,706 filed on February 4, 2019. The entire disclosure of the above-referenced application is incorporated herein by reference.

FIELD OF THE DISCLOSURE

Embodiments described herein generally relate to methods and systems for providing services which securely upgrade an untrusted channel into a trusted channel on a digital platform. In an implementation, a secure remote commerce (SRC) platform is configured to upgrade an untrusted channel to a trusted channel in order to perform secure one-time password (OTP) processing on behalf of issuer financial institutions (FI’s), which allows for secure and fast mass deployment of SRC transactions by removing the necessity for each issuer FI to handle such costly and complex security operations.

BACKGROUND

Remote commerce, or Internet-based commerce, continues to grow in popularity as a purchasing environment for consumers and is typically serviced by a wide variety of stakeholders. In a typical situation, a consumer enters his or her payment card’s Primary Account Number (PAN) into a merchant’s shopping application or website. Currently, many different types of integration models and practices exist for Internet-based commerce, and the variety of implementations and lack of common specifications results in fragmentation, complexity, and

inconsistency.

Portable consumer electronic devices, such as smartphones, tablet computers, digital music players and the like, have been developed that include desirable functionality and thus the number of mobile device users and/or owners keeps growing. Such mobile devices can store many different types of information and can perform many different operations for users. The overall popularity of such mobile devices, especially smartphones, has led to the development of processes for using them to conduct financial transactions, for example, transmission of a payment between a payer (a consumer or payment card account holder or cardholder) and a recipient (or payee, such as a merchant or another cardholder) in exchange for goods and/or services. Of course, personal computers and other non-portable digital devices or appliances that are connected to the Internet and support browser software, may also store many different types of information and may also be utilized by a user to perform many different types of operations, including conducting financial transactions. In a typical purchase transaction, for example, a consumer may utilize a digital wallet application (which includes, for example, the consumer’s payment card account data) running on his or her smartphone (or on a non-portal consumer device) to make a purchase from a merchant. In some implementations, a web browser is utilized by the consumer to shop at a merchant’s website and to conduct a purchase transaction. A merchant device (such as a merchant server computer) then transmits consumer payment card account data to a payment network. The payment network identifies the issuer financial institution (FI) (for example, a bank) that issued the consumer’s payment card account, and then transmits the payment data to that issuer FI for consumer authentication and payment transaction authorization. If all is in order, the merchant device receives a payment transaction authorization message to complete the purchase transaction.

Secure Remote Commerce (SRC) is an evolution of remote commerce that provides for secure and interoperable card acceptance established through a standard technical framework and specification, which is promulgated by EMVCo, LLC (The acronym“EMV” stands for“Europay, Mastercard, Visa,” and denotes a global standard for chip-based credit card account and debit card account transactions that ensures security and global acceptance of such accounts.) SRC enables a merchant (or its agent) to securely request and receive interoperable payment data used to process accepted cards in a remote commerce transaction (such as an Internet purchase transaction). Thus, SRC is a common approach that provides security and interoperability to deliver a safe card payment experience in a remote environment.

The goal of SRC is to enable the secure exchange of payment information through common interfaces between participating entities, which may include, for example, consumers, merchants and issuers. EMVCo published a technical framework which provides guidance for participation in an SRC Program, and a specification which provides requirements for stakeholders who actively

interact with an SRC System. The technical framework is the foundation which includes broad SRC concepts and payment ecosystem considerations for the establishment of an SRC Program, and it includes roles and functions for stakeholders who participate. The specification is an extension of the technical framework, which provides requirements for the SRC ecosystem. The specification also includes requirements and data definitions for specific use cases, and can be found at

www.emvco.com/emv-technologies/src/. An SRC system may work with, or comprise, or be comprised by, a Trusted Service Provider (such as the“Mastercard Digital Enablement Service” (MDES) platform developed by Mastercard International Incorporated, the assignee of the present application) which provides a suite of on-behalf-of (OBO) services that support the management, generation, provisioning and utilization of digital payment credentials (such as tokens), for example, into and/or using mobile devices and/or wallet servers.

The General Data Protection Regulation (GDPR) is a regulation passed by the European Union (EU) in May 2018 that shifts the ownership of customer data from the organizations that use it to the individual customer. This regulation applies to European businesses that work with the customer data of EU citizens and it also applies to any entities that work with those businesses as well, thus making GDPR a global data protection law. Failure to comply with the GDPR can result in a hefty fine, and thus businesses recognize that they must have systems and processes in place that comply with the regulation.

The GDPR mandates that companies receive customer consent before processing or storing customer data. The request for consent must be laid out in plain, straightforward language and must clearly explain how the customer’s data will be used and for how long it will be used and stored. In the past, silence and/or inactivity from the customer was taken as consent, but that is no longer the case with GDPR because companies must be able to prove that they received approval from customers to use their information. Furthermore, the terms of consent need to be consistently accurate with the customer’s most up-to-date information and the purpose for which the data is being used. If either condition changes, the company must obtain an updated consent from the customer. Lastly, customers have the right to withdraw consent at any time, which requires companies to respond and act upon the request in a reasonable timeframe.

The present inventors have recognized that there are opportunities for providing methods which provide services to Issuers which facilitate their participation in SRC transactions and which are also GDPR compliant, and which also remove the burden of costly and complex security operations from the Issuers.

BRIEF DESCRIPTION OF THE DRAWINGS

Features and advantages of some embodiments of the present disclosure, and the manner in which the same are accomplished, will become more readily apparent upon consideration of the following detailed description taken in conjunction with the accompanying drawings, which illustrate exemplary embodiments and which are not necessarily drawn to scale, wherein:

FIG. 1 is a block diagram of a user authentication system to illustrate a One-Time-Password (OTP) authentication process in accordance with embodiments of the disclosure;

FIG. 2 is a flow diagram illustrating a process for upgrading an untrusted channel to a trusted channel in accordance with the disclosure;

FIG. 3 is a block diagram of a verifier server computer to illustrate aspects according to embodiments of the disclosure; and

FIG. 4 is a flowchart of a verifier service process for upgrading according to aspects described herein.

DETAILED DESCRIPTION

Reference will now be made in detail to various novel embodiments, examples of which are illustrated in the accompanying drawings. It should be understood that the drawings and descriptions thereof are not intended to limit the invention to any particular embodiment(s). On the contrary, the descriptions provided herein are intended to cover alternatives, modifications, and equivalents thereof. In the following description, numerous specific details are set forth in order to provide a thorough understanding of the various embodiments, but some or all of these embodiments may be practiced without some or all of the specific details. In other instances, well-known process operations have not been described in detail in order not to unnecessarily obscure novel aspects.

A number of terms will be used herein. The use of such terms is not intended to be limiting, but rather, the terms are used for convenience and ease of exposition. For example, as used herein, the term“consumer” may be used interchangeably with the terms“account holder,”“cardholder,”“prover,” and/or “user” and are used herein to refer to a person, individual, business or other entity that owns (or is authorized to use) a financial account such as a payment card account (for example, a credit card account). In addition, the term“payment card account” may include a credit card account, a debit card account, and/or a deposit account or other type of financial account that an account holder may access. The term“payment card account number” includes a number that identifies a payment card system account, or a number carried by a payment card, and/or a number that is used to route a transaction in a payment system that handles debit card and/or credit card transactions and the like. Moreover, as used herein the terms“payment card system” and/or “payment network” refer to a system and/or network for processing and/or handling purchase transactions and related financial transactions, which may be operated by a payment card system operator such as Mastercard International Incorporated (the assignee of the present application) or a similar system. In some embodiments, the term“payment card system” may be limited to systems in which member financial institutions (such as banks) issue payment card accounts to individuals, businesses and/or other entities or organizations.

In general, methods and systems disclosed herein transform a

Consumer-Verifier untrusted channel into a trusted channel for one-time password (OTP) use, regardless of the framework. However, some embodiments described herein utilize a payment system framework for ease of understanding, which should not be understood as limiting the process. For example, in order to allow the mass deployment of secure remote commerce (SRC) transactions for use by consumers, the operator of an SRC system provides services to Issuer financial institutions (FIs) to ease their participation in SRC transactions. In this manner, the SRC system removes the responsibility for costly and complex security operations from the Issuer FIs. Specifically, the operator of the SRC System offers tokenization by default, provides payment assurance data (cryptograms) by running platform-based 3DS2 processes, and handles security assurance services regarding adding consumer digital payment cards via Cardholder Authentication. All of the above rely on the use of One-Time-Password (OTP) security-based mechanisms based on trusted channels, for example, e-mail and/or mobile telephone numbers known to be associated with the consumer.

This is true both for the case wherein the OTP mechanism is handled directly by a platform (such as the Mastercard Digital Enablement Services (MDES) platform operated by Mastercard International Incorporated for tokenization) or by an access control server (ACS) of the 3DS2 system operated by the SRC System (for proof of payment). However, since the SRC System does not own the consumer (who belongs to the Issuer FI, or to the bank that issued the consumer’s payment account) then a trust or confidence process must be used to transfer trust from the Issuer FI to the SRC System (via upgrading an untrusted channel to a trusted channel) to allow the SRC System to handle secure OTP processing on behalf of the Issuer FI or bank.

Thus, in general, and for the purposes of introducing concepts of novel embodiments described herein, described are systems and processes for transforming or upgrading an untrusted consumer channel into a trusted consumer channel, which permits a Secure Remote Commerce (SRC) System to securely handle one-time password (OTP) processing on behalf of, for example, an Issuer financial institution (FI). Within an SRC System, each consumer has payment card account data (or digital payment card data) stored within a storage element of, for example, a consumer mobile device and/or a browser, and/or a server. The account data for the consumer payment cards is set in a tree data structure along with the consumer’s device and the consumer device identifier, which may be referred to as a Consumer Profile (CP). Within this structure, all of the digital card data (which may be tokenized) representing multiple payment card accounts of the consumer are stored as data leaves of the tree data structure, regardless of the Issuer FI associated with any particular physical and/or digital payment card or payment card account. The tree data structure is rooted in the Consumer Identity (Cl), which is a unique identifier utilized across all SRC Systems. Accordingly, the consumer must be able to easily remember her Cl when she wants to refer to the Consumer Profile and its digital payment cards (i.e., its "leaves") for any operational needs. Therefore, the Cl must be "user friendly" and "easy to remember" while still being unique. For these reasons, e-mail addresses and/or mobile telephone numbers are good candidates for use as a Cl in the Consumer Profile because such identifiers are easy to remember and guarantee uniqueness within the SRC ecosystem. Accordingly, in some embodiments, the consumer’s e-mail address is utilized as a Cl when the consumer creates his or her identity during subscription or enrollment with the SRC System. In this case, the SRC System

considers the consumer’s e-mail channel as an untrusted channel, since the SRC System does not know and/or has no evidence or proof during subscription or enrollment that the e-mail channel is in fact associated with the consumer.

Accordingly, in some embodiments, starting from an existing consumer trusted channel known to the Issuer FI, a consumer’s untrusted channel can be registered with the SRC System space and then can become a trusted channel for secure use with a one-time password (OTP) authentication mechanism under certain conditions. Specifically, the untrusted channel can become a trusted channel using the disclosed methods if: (a) the consumer or user does not grant consent for sharing the Consumer Identity (Cl) with the Issuer FI, or (b) the Issuer FI indicated its wish to outsource SRC transaction security to the SRC System (for example, by offering this service to its customers as being the easiest and most intuitive consumer or user experience). In other embodiments, starting from an existing consumer trusted channel known to the Issuer FI, an untrusted channel registered with the SRC System can become a trusted channel if: (a) the Issuer FI does not want to outsource SRC transaction security to the SRC System; (b) the consumer consents to having the SRC System provide his or her Consumer Identity (Cl) to the Issuer FI; and (c) the Issuer FI wants to offer its’ consumers or users an intuitive user experience. It should be noted that both of the above scenarios are GDPR compliant. In addition, in some embodiments increasing or upgrading the trust of the consumer channel from

"untrusted" to "trusted" can be realized in real time when the consumer selects an “SRC button," for example, during a“card add” process or during an SRC payment transaction. Such processing is advantageous because it does not require a separate "out-of-band" user experience which would force a consumer to provide additional information via one or more interfaces in preparation for the SRC transaction, which extra steps are somewhat inconvenient and may cause the consumer to abandon the transaction.

FIG. 1 is a block diagram of a user authentication system 100 for illustrating how a One-Time-Password (OTP) authentication mechanism operates in accordance with the disclosure. In some embodiments, the user authentication system 100 includes a user mobile device 102 (for example, an iPhone™ or an Android™ smartphone, a tablet computer such as an iPad™, a laptop computer, a digital music player, a personal digital assistant (PDA) and the like), a verifier computer 104, a verifier database 106, and user computer 108. In implementations, the user mobile device 102 may run browser software, for example, and communicate via the Internet with the verifier computer 104. The verifier computer 104 may also be configured for communicating via the Internet 110 with the user computer 108. It should be understood that some of the various components shown in FIG. 1 may be a subset of a larger system, and therefore that more or less components and/or devices may be utilized. For example, although only one user mobile device 102 and one verifier computer 104 are shown, in some practical embodiments a plurality of such devices or components may be utilized. In addition, although specific embodiments are described herein, it should be understood that this is for illustrative purposes only and that different components and/or configurations and/or computer systems and/or computer networks could be used without departing from the spirit and scope of this disclosure.

The OTP authentication protocol is one of the most used two-factor authentication mechanisms for Internet security and/or e-commerce security and/or digital security in use today. One reason for its popularity is that no requirement exists for using complicated cryptographic mechanisms and/or programs which include complex key management requirements and/or require difficult user setup routines. Instead, an OTP authentication protocol can be initialized and deployed during real-time operation by the user and is rather easy for that consumer to utilize.

In order to utilize an OTP mechanism, the consumer must first enroll or register offline and create a trusted channel (or tenured channel) with a Verifier.

For example, in one method the consumer may register an e-mail address of “email_addrl” during a face-to-face interaction with a representative of the Verifier institution (for example, a bank representative when opening a bank checking account or applying for a bank credit card account), which knows the consumer because the verifier identified the consumer previously. In some implementations, the consumer may have registered a set of security questions with the Verifier’s representative, which may have been selected by the consumer from a list of pre-established questions provided by the Verifier. In some embodiments the answers to the security questions are communicated in a face-to-face meeting with the Verifier’s

representative. The security questions and consumer answers are then stored in connection with a consumer identifier for use in the future. Thus when the consumer enrolls remotely with a Verifier’s service, he or she provides e-mail address information and or mobile telephone number information on the Verifier’s website. The consumer may be required to provide, using his or her email address or mobile telephone number, answers to one or more security questions which were chosen by the him or her and wherein the answers are known to the Verifier (which were already pre-established and which may be presented in a menu format to the consumer). If the consumer provides the correct answers, the Verifier has confirmation that the new e-mail and/or mobile phone number represents a trusted channel associated with the consumer.

Due to the enrollment process, the Verifier recognizes that future e-mail and/or mobile communications will occur via a trusted channel with the consumer. Thus, after completing the enrollment process, in the future the consumer can use the OTP authentication service (as a two-factor authentication mechanism). The Verifier (such as a bank or Issuer FI) searches for the consumer’s e-mail address (email_addrl in this example), based on his or her identifier (ConsumerJOD), finds the e-mail address which represents a first factor (something the consumer has), and then sends an e-mail message (to email_addrl) that includes a one-time password for the consumer, which represents the second factor (something the consumer knows). The consumer receives the e-mail message, opens it, and utilizes the OTP to prove his or her identity by transmitting back this OTP to the verifier service.

The OTP consists of a randomly generated special code which the consumer must transmit back to the Verifier’s service before it expires (which expiration time, such as 30 seconds or 5 minutes, for example, may be specified by the Verifier and may depend on details or criteria of the transaction).

Referring again to FIG. 1, the OTP mechanism functions in the following manner. A consumer utilizes his or her mobile device 102 (or user computer 108) to enroll or register via the Internet 110 with the verifier computer 104 of the verifying party, as explained above. Thus, the Verifier computer 104 recognizes that a communication channel (for example, the consumer’s e-mail address or mobile telephone number) is associated with the consumer and is labeled as a trusted channel because the Verifier computer knows it to be associated with the consumer. Next, when the consumer’s mobile device 102 wants to demonstrate its identity to get access to a service run by the Verifier computer 104, the consumer mobile device 102 transmits its identity to the Verifier computer 104 on the service interface. The Verifier computer 104 retrieves from its Verifier service database 106 the trusted channel associated with the consumer's identity and then generates, for the current authentication session, a message such as“OTP_witness” at random. The Verifier computer 104 then transmits the“OTP_witness” message to the consumer (for example, via the Internet to the consumer’s mobile device) using the trusted channel. The consumer retrieves the OTP witness message from the trusted channel and replies to the OTP witness message by transmitting the value or code in that message back to the Verifier computer 104 as an OTP value on the service interface. The Verifier computer 104 then determines whether or not the OTP_value it received from the consumer mobile device 102 matches the value contained in the

OTP_witness message. If it does match, then the Verifier computer 104 is persuaded that the consumer "owns" the communication channel and designates it as "something you have" (which is the first factor of a two-factor authentication process) since the consumer would not otherwise be able to access the OTP_witness message. In addition, since the consumer knows the value of the OTP witness message, the Verifier computer 104 is persuaded that the consumer has "something you know" (which is the second factor), meaning that the consumer is indeed at the other end of the communication during this process. Such operation can be considered a two-factor authentication method that is“payment services directive two” (PSD2) compatible, for example, if the following security assumptions are true: (1) The telecom operator (who provides telecommunications services to the consumer’s device), which really owns the e-mail channel and/or mobile telephone channel, does not interfere by eavesdropping as long as the consumer respects his contractual obligations; and (2) a hacker cannot control the consumer’s device by taking advantage of hardware or software weaknesses of that device.

With regard to the OTP process described above, the decision to utilize an e-mail address (or a mobile phone number) as the Consumer Identity (Cl) of a user in the SRC system may create confusing and/or conflicting consequences.

If the Issuer FI needs assurance from the consumer concerning the addition of another digital card to her Consumer Profile ( ., the consumer wishes to add a new leaf to the Consumer Profile data structure), then the SRC System's channel associated with the Cl cannot be utilized in an OTP authentication mechanism, for the following two reasons. First, the consumer provided this e-mail address (or alternatively, mobile phone number) to the SRC System, and did not provide it to the Issuer FI; thus, in order to stay GDPR compliant the SRC System cannot make the Cl known to the Issuer FI without the explicit consent of the consumer. Second, the SRC System e-mail address of the Consumer is untrusted for both the SRC System and the Issuer FI because the SRC System does not know whether or not that e-mail address actually belongs to that consumer (since the SRC System has no way to know how the Consumer may be associated with that e-mail address from any other out-of-band experience, digital activity, or the like). However, the consumer’s expectation is that, after enrolling with SRC System under her chosen Cl, any subsequent operations (and especially any user assurance-related operations for Cardholder Authentication to securely add new card accounts or for using the SRC payment method) would utilize that Cl email address without needing any further input from the consumer.

Consequently, the consumer would be surprised and possibly confused when approached for SRC related operations on a different e-mail address and/or mobile telephone number than the Cl provided to the SRC System at enrollment. The different e-mail and/or mobile channels may be known to Issuer FIs and to other Wallet Providers and/or Token Requestors from previous interactions concerning digital payment activities with the consumer (/.