Efficient and secure authentication system

Abstract

A system and method of establishing a resource provider as a trusted list entry is disclosed. The method includes receiving, by a directory server computer, an indication from a user that a resource provider is trusted. The directory server computer is programmed to provide a first level of authentication. The method then includes storing data representing the indication from the user that the resource provider is trusted in a database. The method then includes receiving, from the user, an authentication request message to interact at the resource provider computer and determining that the data representing the indication from the user that the resource provider is trusted is present. In response to the determination, the method includes providing a second level of authentication to the user before the user is allowed to complete the interaction. The second level of authentication is lower than the first level.

Description

[0001] This application is a continuation-in-part of International Application No. PCT / US2019 / 028880, International Filing Date, which entered the National Stage in the United States as U.S. Patent Application No. 16 / 868,414, on April 24, 2019, entitled “Highly Efficient and Secure Authentication System,” the disclosure of which is incorporated by reference herein in its entirety.

[0002] Related Applications

[0003] This application is a non-provisional of U.S. Provisional Application No. 62 / 662,134, filed April 24, 2018, U.S. Provisional Application No. 62 / 662,648, filed April 25, 2018, and U.S. Provisional Application No. 62 / 728,303, filed September 7, 2018, which claims the benefit of the filing date of each of the U.S. Provisional Applications, and which are incorporated by reference herein in their entirety. BACKGROUND

[0004] Strong authentication of a user can be an important component of protecting sensitive user data and maintaining security during an interaction. Strong authentication can require additional authentication steps, such as multi-factor authentication, additional passwords, biometric inputs, etc. This can let a user ensure that their sensitive data is protected and that the interactions they conduct are secure. Strong authentication can be implemented, for example, in payment transactions and for secure database access. In particular, during payment transactions, authentication systems like 3D Secure can provide a high level of security. One problem, however, is that strong authentication can sometimes be too strong. Requiring too many authentication steps or making the process too difficult even for legitimate users can have a negative impact on the service or resource provider that uses strong authentication. In some cases, users and / or resource providers can opt for less secure authentication methods, leaving sensitive data at risk. Additional unnecessary authentication can also create a large number of authentication messages that can unnecessarily consume too many computing resources.

[0005] Embodiments of the present invention address these and other problems individually and collectively. SUMMARY

[0006] One embodiment of the invention includes receiving, by a directory server computer from a user, an indication that a resource provider is trusted, wherein the directory server computer is programmed to provide a first level of authentication, and storing, by the directory server computer, data representing the indication from the user that the resource provider is trusted in a database. The method then includes receiving, by the directory server computer from the user, an authentication request message to interact at a resource provider computer, and determining, by the directory server computer, that the data representing the indication from the user that the resource provider is trusted exists. In response to the determination, the method includes providing, by the directory server computer to the user, a second level of authentication before the user is allowed to complete the interaction, wherein the second level of authentication is lower than the first level of authentication.

[0007] Another embodiment of the invention includes a directory server computer comprising a processor and a computer readable medium coupled to the processor, the computer readable medium comprising code executable by the processor to implement a method comprising receiving, from a user, an indication that a resource provider is trusted, wherein the directory server computer is programmed to provide a first level of authentication, and storing data representing the indication from the user that the resource provider is trusted in a database. The method then includes receiving, from the user, an authentication request message to interact at the resource provider computer, and determining that the data representing the indication from the user that the resource provider is trusted exists. In response to the determination, the method includes providing a second level of authentication to the user before the user is allowed to complete the interaction, wherein the second level of authentication is lower than the first level of authentication.

[0008] Another embodiment of the invention includes a system comprising a directory server computer comprising a first processor and a first computer readable medium, the first computer readable medium comprising code executable by the first processor to implement a method comprising sending a trusted flag to a resource provider computer. The system also includes a processing computer comprising a second processor and a second computer readable medium, the second computer readable medium comprising code executable by the second processor to implement a method comprising receiving an interaction authorization request message, the authorization request message comprising a trusted flag. The method then includes validating the trusted flag and sending the authorization request message comprising the trusted flag to an authorization entity computer.

[0009] Another embodiment of the invention includes receiving, by a processing computer, an authorization request message for an interaction between a user and a resource provider, the authorization request message comprising a trusted flag. The method then includes validating, by the processing computer, the trusted flag and sending, by the processing computer, the authorization request message comprising the trusted flag to an authorization entity computer.

[0010] Another embodiment of the invention includes a resource provider computer requesting a trusted listing status from a user and sending a trusted listing request message to a directory server computer. The method then includes the resource provider computer receiving a trusted listing response message from the directory server computer, the trusted listing response message indicating that the user has been authenticated at a first level of authentication and including a trusted flag. Then, the method includes the resource provider computer sending an interaction authentication request message to the directory server computer, the authentication request message including the trusted flag, and the resource provider computer receiving an authentication response message from the directory server computer, the authentication response message indicating that the user has been authenticated at a second level of authentication, where the second level of authentication is lower than the first level of authentication.

[0011] Another embodiment of the invention includes a resource provider computer including a processor and a computer readable medium coupled to the processor, the computer readable medium including code executable by the processor to implement a method including requesting a trusted listing status from a user and sending a trusted listing request message to a directory server computer. The method then includes receiving a trusted listing response message from the directory server computer, the trusted listing response message indicating that the user has been authenticated at a first level of authentication and including a trusted flag. Then, the method includes sending an interaction authentication request message to the directory server computer, the authentication request message including the trusted flag, and receiving an authentication response message from the directory server computer, the authentication response message indicating that the user has been authenticated at a second level of authentication, where the second level of authentication is lower than the first level of authentication.

[0012] Further details regarding embodiments of the invention can be found in the DETAILED DESCRIPTION and the accompanying drawings. BRIEF DESCRIPTION OF DRAWINGS

[0013] Figure 1 A block diagram of a system according to an embodiment is shown.

[0014] Figure 2 A block diagram of a directory server computer according to an embodiment is shown.

[0015] Figure 3 A block diagram of a processing computer according to an embodiment is shown.

[0016] Figure 4 A registration swim lane diagram according to an embodiment is shown.

[0017] Figure 5 An authorization swim lane diagram according to an embodiment is shown.

[0018] Figure 6 A subsequent authentication and authorization swimlane diagram showing trusted list items according to embodiments is shown.

[0019] Figures 7A-7C An exemplary screenshot of a transaction according to embodiments is shown.

[0020] Figure 8 An exemplary screenshot of a resource provider site according to embodiments is shown.

[0021] Figure 9 An exemplary screenshot of an issuer site according to embodiments is shown. DETAILED DESCRIPTION

[0022] Embodiments of the present invention can reduce the time and resources spent on authentication. In particular, in embodiments of the present invention, a user can indicate that they trust a resource provider and mark the resource provider as a trusted list item, thereby avoiding strong authentication for subsequent interactions with that resource provider. The resource provider can be required to provide proof that the user has requested the trusted list item. An authentication entity (e.g., an access control server, an issuer) can be able to manage trusted list items (e.g., remove a resource provider as a trusted list item for a user). In embodiments, a resource provider can request additional authentication using an existing strong authentication process.

[0023] While there are multiple implementation options, embodiments can include one or more components. The components can include: strong authentication when creating a trusted list item (e.g., authenticating a user by biometric or one-time password), the ability of an authentication entity to remove a trusted list item, proof that a trusted list item is still active / valid (e.g., an indicator or flag that a trusted list item has been verified).

[0024] Embodiments of the present invention can provide exemplary systems, apparatuses, and methods for conducting transactions and related activities. While such transactions can be referenced in the examples provided below, embodiments are not limited thereto.

[0025] Prior to discussing embodiments of the present invention, some terminology can be described in greater detail.

[0026] A "user" can include an individual. In some embodiments, a user can be associated with one or more individual accounts and / or mobile devices. In some embodiments, a user can also be referred to as a cardholder, account holder, or consumer.

[0027] A "resource provider" can be an entity that can make resources available to a user. Examples of resource providers include merchants, vendors, suppliers, owners, traders, and the like. In some embodiments, such entities can be a single individual, a small group of individuals, or a larger group of individuals (e.g., a company). A resource provider can be associated with one or more physical locations (e.g., a supermarket, a mall, a store, and the like) and online platforms (e.g., a mobile application, an e-commerce website, an online company, and the like). In some embodiments, a resource provider can make physical items (e.g., goods, products, and the like) available to a user. In other embodiments, a resource provider can make digital resources (e.g., electronic documents, electronic files, and the like) available to a user. In other embodiments, a resource provider can manage a user's access to certain resources (e.g., passwords, codes, and the like).

[0028] A "resource provider computer" can include any system associated with a resource provider. In some embodiments, a resource provider computer can handle the functionality of a mobile application and / or a website associated with a resource provider through which a user can conduct online transactions. A resource provider computer can also be referred to as a resource provider computing device.

[0029] An "acquirer" can be a business entity (e.g., a commercial bank) that has a business relationship with a particular resource provider or other entity. Some entities can perform both issuer and acquirer functions. Some embodiments can encompass such single entity issuer-acquirers. An acquirer can operate an acquirer computer, which can also be generally referred to as a "transport computer."

[0030] An "authorization entity" can be an entity that authorizes a request. Examples of authorization entities can be an issuer, a government agency, a document repository, an access administrator, and the like. An authorization entity can operate an authorization entity computer.

[0031] An "issuer" can be a business entity (e.g., a bank) that maintains an account for a user. An issuer can also issue payment credentials to a user that are stored on a user device such as a cell phone, a smart card, a tablet, or a laptop.

[0032] A "payment processing network" can be a data processing subsystem, network, and operation to support and deliver authorization services, exception file services, and clearing and settlement services. An exemplary payment processing system can include VisaNet®. For example, VisaNet® TM includes its base IIA and BIIA systems, which combine to form what is commonly referred to as "the VisaNet." VisaNet® TMA payment processing system of the type described herein can be capable of processing credit card transactions, debit card transactions, and other types of commercial transactions. Authorization, settlement, and clearing can be performed simultaneously (substantially simultaneously, e.g., within minutes or hours), or can be performed as part of a batch settlement process (e.g., at the end of a day or week). A payment processing network can include server computers. A payment processing network can use any suitable wired or wireless network, including the Internet.

[0033] An "authentication request message" can be an electronic message sent to one or more computing devices to request authentication of an interaction. In some embodiments, an authentication request message can be an electronic message sent to a payment processing network and / or an issuer of an account to request authentication of a transaction. In some embodiments, an authentication request message can include user, resource provider, and transaction specific information. According to some embodiments, an authentication request message can conform to HTTP standards, which can be defined according to HTTP Messaging specifications, and can be an HTTP "GET" or "POST" message.

[0034] An "authentication response message" can be an electronic message reply to an authentication request. In some embodiments, an authentication response message can be generated by an issuer or a payment processing network. In some embodiments, an authentication response message can include user, resource provider, and transaction specific information. According to some embodiments, an authentication response message can conform to ISO 8583, which is a standard for systems that exchange electronic transaction information associated with payments made by users using payment devices or payment accounts.

[0035] An "authorization request message" can be a message sent to request authorization of an interaction. An authorization request message can be sent to, for example, a secure data server, a payment processing network, an issuer of a payment card, a processing gateway, etc. An authorization request message can also include additional data elements corresponding to "identification information," including, for example, a service code, a user identifier, a CVV (card verification value), an expiration date, etc. An authorization request message can also include "interaction data," such as any information associated with a current interaction, such as an interaction value, a timestamp, a resource provider identifier, a resource provider location, etc., and any other information that can be used to determine whether to authorize an interaction. An authorization request message according to some embodiments can conform to ISO 8583, which is a standard for systems that exchange electronic transaction information associated with payments made by users using payment devices or payment accounts.

[0036] An "authorization response message" can be a message reply to an authorization request message. An authorization response message can be generated, for example, by a secure data server, an issuing financial institution, a payment processing network, a processing gateway, etc. An authorization response message can include, for example, one or more of the following status indicators: approved - the interaction was approved; declined - the interaction was not approved; or call center - more information for the response pending, the resource provider must call a toll-free authorization phone number. An authorization response message can also include an authorization code, which can be a code returned by an authorizing entity to a resource provider's access device in response to an authorization request message in an electronic message, indicating that a transaction is approved. The code can serve as proof of authorization.

[0037] A "server computer" can be a powerful computer or cluster of computers. For example, the server computer can be a large mainframe, a minicomputer cluster, or a group of servers acting in concert. In one example, the server computer can be a database server coupled to a Web server. The server computer can be associated with, for example, a merchant, a payment processing network, a wallet provider, a merchant, an authentication cloud, an acquirer, or an issuer.

[0038] A "user device" can be any suitable electronic device that can process information and communicate that information to other electronic devices. A user device can include a processor and a computer- readable medium coupled to the processor, the computer-readable medium comprising code executable by the processor. User devices can also each include an external communication interface for communicating with each other and other entities. Examples of user devices can include mobile devices, laptop or desktop computers, wearable devices, etc.

[0039] A "credential" can be any suitable information that serves as reliable evidence of worth, ownership, identity, or authority. A credential can be a string of numbers, letters, or any other suitable characters, as well as any object or document that can be used as confirmation. Examples of credentials include value credentials, identification cards, authentication documents, access cards, passwords and other login information, etc.

[0040] A "payment credential" can include any suitable information associated with an account (e.g., a payment account and / or a payment device associated with an account). Such information can be directly related to an account, or can be derived from information related to an account. Examples of account information can include a PAN (primary account number or "account number"), a user name, an expiration date, and a verification value, such as a CVV, dCVV, CVV2, dCVV2, and CVC3 value.

[0041] A "stored credential transaction" can be a transaction in which a resource provider uses a previously stored payment credential from a user. A stored credential transaction can also be referred to as a credential-on-file or card-on-file transaction. Stored credential transactions can be used, for example, for installment payments or for convenience for the resource provider or the user.

[0042] A "token" can be a substitute value for a credential. A token can be a string of numbers, letters, or any other suitable characters. Examples of tokens include payment tokens, access tokens, personal identification tokens, and the like.

[0043] A "payment token" can include a payment account identifier that substitutes for an account identifier such as a primary account number (PAN). For example, a payment token can include a series of alphanumeric characters that can be used as a substitute for an original account identifier. For example, the token "4900 00000000 0001" can be used in place of a PAN "4147 0900 00001234." In some embodiments, a payment token can be "reserved format" and can have a numeric format consistent with account identifiers used in existing transaction processing networks (e.g., the ISO 8583 financial transaction message format). In some embodiments, a payment token can be used in place of a PAN to initiate, authorize, settle, or resolve a payment transaction, or to represent an original credential in other systems that would normally provide the original credential. In some embodiments, a payment token can be generated such that it can not be computationally possible to derive a recovery of the original PAN or other account identifier from the token value. Further, in some embodiments, a payment token format can be configured to allow an entity receiving the payment token to identify it as a payment token and to recognize the entity that issued the payment token.

[0044] "Tokenization" is the process of replacing data with substitute data. For example, a payment account identifier (e.g., a primary account number (PAN)) can be tokenized by replacing the primary account identifier with a substitute number (e.g., a token) that can be associated with the payment account identifier. Further, tokenization can apply to any other information that can be replaced with a substitute value (i.e., a token).

[0045] A "token service system" can include a system that provides token services. In some embodiments, a token service system can facilitate requesting, determining (e.g., generating), and / or issuing tokens, as well as maintaining, in a repository (e.g., a token vault), a mapping of established tokens to primary account numbers (PANs). In some embodiments, a token service system can establish a token assurance level for a given token to indicate a level of confidence that the token is bound to a PAN. A token service system can include or be in communication with a token vault in which generated tokens are stored. By detokenizing a token to obtain an actual PAN, a token service system can support token processing of payment transactions submitted using tokens. In some embodiments, a token service system can include only a tokenization computer, or a tokenization computer in combination with other computers such as transaction processing network computers. Various entities of a tokenization ecosystem can assume the role of a token service provider. For example, a payment network and an issuer or its agent can become a token service provider by implementing token services.

[0046] A "plug-in" (or "PI") can be a computer component that represents an entity performing a particular function. For example, a plug-in can perform various authentication functions. A plug-in can be used by a resource provider. A plug-in can be embodied by suitable hardware and / or software accessible to a resource provider. For example, a plug-in can be software running on a resource provider computing device, or can be a component running on a different server accessible to the resource provider. A plug-in can be capable of performing various functions, such as determining whether an authentication is available for an account identifier, verifying a digital signature in an authentication message, and other functions.

[0047] An "access control server" (or "ACS") can provide an authorized entity with the ability to authenticate a user during an online transaction. An ACS performs requested authentication services and provides digitally signed responses to entities requesting authentication. An ACS can be shared by multiple entities. Additionally or alternatively, an entity can have multiple access control servers, each associated with a different subset of users.

[0048] A "directory server" can be used to route messages containing registration and authentication information between plug-ins (PIs) and ACSs. A directory server can also determine whether a user can utilize an authentication service. In some embodiments, a directory server can be operated by a service organization such as Visa. A directory server can include a directory server computer.

[0049] An entity can be "trusted" if the entity is considered reliable or honest. An entity can build trust over time. Trust can be built, for example, by repeated successful interactions, successful authentications, and the like. An entity can also be trusted due to an association with another trusted entity, such as a government entity.

[0050] A "trusted list item" can be an entity that is trusted by another entity. For example, if a user is familiar with a resource provider and has conducted many transactions with it without problems, the user can indicate that the resource provider is a trusted list item. An entity that is a trusted list item can be referred to as having a trusted list item status and / or being trusted. In some embodiments, a trusted list item can be referred to as being on a whitelist and / or being whitelisted.

[0051] A "trusted flag" can be an indicator that an entity is a trusted list item. For example, a trusted flag can be used in an authorization request message to indicate that the entity sending the authentication request message is trusted by the entity authenticating the user.

[0052] An "authentication level" can be associated with a particular authentication strength. Different authentication levels can have different protocols and different levels of assurance or strength. For example, a first level of authentication can be provided by an entity such as a directory server, an access control server, or the like. The first level of authentication can be a relatively high level of authentication and can or can not be the highest level of authentication provided by the authenticating entity. The first level of authentication can be a strong authentication. Examples of the first level of authentication can include two- or multi-factor authentication, biometric authentication, passwords and passcodes. In another example, a second level of authentication can be lower than the first level of authentication. The second level of authentication can be provided by an entity such as a directory server, an access control server, or the like. In some embodiments, the second level of authentication can be no authentication. Other examples of the second level of authentication can include a PIN and retrieving data from a device.

[0053] One embodiment of the invention relates to a method. The method includes receiving, by a directory server computer, an indication from a user that a resource provider is trusted. The indication can state that the user confirms that the resource provider is a trusted list item. Trust can be developed in a number of ways. For example, trust between a user and a resource provider can be developed because the user has conducted a large number of transactions with the resource provider without problems.

[0054] The directory server computer can be programmed to provide (e.g., perform or initiate) a first level of authentication. For example, the directory server computer can be programmed to initiate an authentication process through an access control server (ACS), which can ask a user for a password. The ACS can return a password or other indicator to the directory server computer to confirm that the user was authenticated by the ACS. In other embodiments, the directory server computer can directly ask a user for a password. Data representing the indication that the resource provider is trusted by the user can be stored in a database. The directory server computer can then send a trusted flag to the resource provider. The trusted flag can allow the resource provider to indicate in subsequent authentication request messages or authorization request messages that the resource provider is trusted by the user.

[0055] At a later point in time, the directory server computer can receive an authentication request message from the user to interact at the resource provider computer. The authentication request message can include a trusted indicia. The directory server computer determines that there is data indicating that the resource provider is trusted from the user. In response to the determination, the directory server computer can apply a second level of authentication to the user before the user is allowed to complete the interaction. The second level can be less or less stringent than the first level. For example, if the first level of authentication requires a password, the second level of authentication can not require a password, or can use device data collected from the user's user device without asking the user for a password.

[0056] Figure 1 A system 100 including several components is shown in accordance with an embodiment of the application. The system 100 can include a user device 120, a resource provider computer 130 with a plug-in 135, a transport computer 140, a processing computer 150, a directory server computer 160, and an authorized entity computer 170 with an access control server (ACS) 175.

[0057] The user device 120, the resource provider computer 130, the transport computer 140, the processing computer 150, the directory server computer 160, the ACS 175, and the authorized entity computer 170 can all be in operative communication with each other over any suitable communication channel or communication network. Suitable communication networks can be any one and / or combination of the following: a direct interconnection; the Internet; a local area network (LAN); a metropolitan area network (MAN); an operational task as a node on the Internet (OMNI); a secure custom connection; a wide area network (WAN); a wireless network (e.g., using a protocol such as, but not limited to, wireless application protocol (WAP), I-Mode, and / or the like); and / or the like. Messages between computers, networks, and devices can be transmitted using a secure communication protocol such as, but not limited to: file transfer protocol (FTP); hypertext transfer protocol (HTTP); secure hypertext transfer protocol (HTTPS), secure sockets layer (SSL), ISO (e.g., ISO 8583), and / or the like.

[0058] User device 120 can allow a user to interact with a resource provider. User device 120 can be, for example, a mobile device such as a smartphone or smartwatch, or a laptop computer. In some embodiments, user device 120 can include an issuer application, such as a mobile wallet application or a payment application for conducting payment transactions. In other embodiments, user device 120 can include an access application, which can have access data to enable user device 120 to conduct access transactions. User device 120 can also store a user identifier and / or an account identifier. Examples of a user identifier can include an alphanumeric string, a phone number, a password, and the like. An account identifier can include an account number, a PAN, a token, a payment credential, an access credential, and the like.

[0059] Resource provider computer 130 can be operated by a resource provider. A resource provider can be, for example, a merchant that sells material goods or a secure data server that provides access to protected data. Resource provider computer 130 can interact with user device 120. Resource provider computer 130 can also have a plug-in 135. Plug-in 135 can allow resource provider computer 130 to communicate with directory server computer 160 and ACS 175.

[0060] A resource provider can have a resource provider identifier, and the resource provider identifier can be stored on resource provider computer 130. In some embodiments, the resource provider identifier can be numeric, alphanumeric, binary, or hexadecimal. For example, the resource provider identifier can be an 8-digit number. The resource provider identifier can be assigned by a processing computer 150 (e.g., a computer in a payment processing network) or directory server computer 160. The resource provider identifier can not depend on the resource provider’s acquirer. This can prevent concurrency situations in cases where the resource provider has a relationship with more than one acquirer. This can also allow the resource provider to maintain the resource provider’s trusted list item status with users even in cases where the resource provider changes acquirers.

[0061] Some resource providers can control multiple brands. For example, a resource provider can have a brand that sells furniture and another brand that sells electronics. The different brands can or can not sell to users in different ways. In some embodiments, each of the resource provider’s brands can receive the same resource provider identifier. Thus, a user can or can not know that multiple brands of the same resource provider can receive a trusted list item status together. In other embodiments, each brand can receive a different resource provider identifier. In this way, each brand can have a different trusted list item status.

[0062] The transport computer 140 can be operated by an acquirer of the resource provider. The transport computer 140 can receive an authorization request message from the resource provider computer 130 and can send the authorization request message to the processing computer 150. The transport computer 140 can also communicate authorization response messages from the processing computer 150 to the resource provider computer 130.

[0063] The processing computer 150 can be part of a payment processing network. The processing computer 150 can participate in the authorization process and can route authorization messages. In some embodiments, the processing computer 150 can perform tokenization and detokenization processes. The processing computer 150 can maintain a trusted list item database of resource providers trusted by a user.

[0064] In some embodiments, the directory server computer 160 can be part of a payment processing network. The directory server computer 160 can participate in the authentication process and can route authentication messages. The directory server computer 160 can maintain a directory that specifies the location and capabilities of entities in the system 100, such as ACSs. The capabilities of an ACS can include whether the ACS supports authentication with strong authentication and / or trusted list items. In some embodiments, the directory server computer 160 can be a strong authentication service provider, such as a 3D Secure (3DS) program server.

[0065] The authorization entity computer 170 can authorize transactions between users and resource providers. The authorization entity computer 170 can communicate with the ACS 175. The authorization entity computer 170 can be operated by an issuer of the user.

[0066] The access control server (ACS) 175 can be a computer, or can be part of the authorization entity computer 170. In some embodiments, the authorization entity computer 170 and the ACS 175 can both be operated by the same entity (e.g., an issuer), but they can be separate computers. The ACS 175 can allow the authorization entity computer 170 to authenticate users as well. The ACS 175 can contain account information, such as an account identifier and a password for each user account.

[0067] Figure 2 A block diagram of the directory server computer 160 according to embodiments of the application is shown. The directory server computer 160 can include a processor 161 coupled to a network interface 162, a memory 163, and a computer-readable medium 166. The computer-readable medium 166 can store code that can be executed by the processor 161 to implement some or all of the functionality of the directory server computer 160 described herein. For example, the computer-readable medium 166 can include an authentication module 166A, a lookup module 166B, a directory module 166C, and a management module 166D.

[0068] The processor 161 can be implemented as one or more integrated circuits (e.g., one or more single-core or multicore microprocessors and / or microcontrollers). The processor 161 can be configured to control operation of the directory server computer 160. The processor 161 can execute a variety of programs in response to program code or computer-readable code stored in the memory 163. The processor 161 can include functionality to maintain multiple concurrently executing programs or processes.

[0069] The network interface 162 can be configured to connect to one or more communication networks to allow the directory server computer 160 to communicate with other entities, such as the transport computer 140, the authorization entity computer 170, the processing computer 150, etc. For example, communications with the authorization entity computer 170 can be direct, indirect, and / or through an API.

[0070] The memory 163 can be implemented using any combination of any number of nonvolatile memory (e.g., flash memory) and volatile memory (e.g., DRAM, SRAM), or any other non-transitory storage medium or combination of media.

[0071] The computer-readable medium 166 can include one or more non-transitory media used to store and / or transmit data. Suitable media include, for example, random access memory (RAM), read only memory (ROM), magnetic mediums, such as a hard disk drive, or optical mediums, such as a compact disc (CD) or DVD (digital versatile disc), flash memory, etc. The computer-readable medium 166 can be any combination of such storage or transmission devices.

[0072] The authentication module 166A, in conjunction with the processor 161, can participate in an authentication process. The authentication module 166A, in conjunction with the processor 161, can receive an authentication request message. The authentication module 166A, in conjunction with the processor 161, can then send the authentication request message to an ACS for authentication. In other embodiments, the authentication module 166A, in conjunction with the processor 161, can directly authenticate a user. The authentication module 166A, in conjunction with the processor 161, can determine what level of authentication should be applied to a user. For example, the authentication module 166A, in conjunction with the processor 161, can determine that a lower level of authentication is appropriate because the user is interacting with a trusted list item.

[0073] The lookup module 166B, in conjunction with the processor 161, can query a trusted list entry database of the processing computer 150. By querying the trusted list entry database, the lookup module 166B, in conjunction with the processor 161, can determine whether there is data indicating that the resource provider is trusted. Such data can include, for example, a flag, a date the trusted list entry was established, a trusted indicia, or some other data field. The lookup module 166B, in conjunction with the processor 161, can query the trusted list entry database using the user identifier or account identifier. In some embodiments, the query can be sent to the processing computer 150, which can query the trusted list entry database. The lookup module 166B can then receive an indication that the resource provider is trusted by the user.

[0074] The directory module 166C, in conjunction with the processor 161, can determine authentication services available to the user. For example, the directory module 166C can determine that the user needs to enroll before using an authentication service. The directory module 166C, in conjunction with the processor 161, can also determine authentication services supported by a particular ACS. For example, the directory module 166C, in conjunction with the processor 161, can determine whether a trusted list entry is supported by the authorization entity. In some embodiments, the directory module 166C can maintain a directory of different authorization entities and authentication services available to the user. In other embodiments, the directory module 166C, in conjunction with the processor 161, can query an entity to determine the authentication services available.

[0075] The management module 166D, in conjunction with the processor 161, can manage trusted list entries. The management module 166D, in conjunction with the processor 161, can change or remove the trusted list entry status of a resource provider. The management module 166D can receive instructions from a user or an ACS (e.g., from an issuer) to update or remove a trusted list entry in the trusted list entry database. Additionally or alternatively, the management module 166D, in conjunction with the processor 161, can periodically remove the trusted list entry status of a resource provider to force re-authentication of the user. If the user receives a new user identifier or new account information, the management module 166D, in conjunction with the processor 161, can transfer the trusted list entry associated with the previous user identifier to the new user identifier. In some embodiments, the management module 166D, in conjunction with the processor 161, can send instructions to the processing computer 150 with the desired changes.

[0076] Figure 3A block diagram of a processing computer 150 according to an embodiment of the application is shown. The processing computer 150 can include a processor 151 coupled to a network interface 152, a memory 153, and a computer-readable medium 156. The computer-readable medium 156 can store code, which can be executed by the processor 151, for implementing some or all of the functionality of the processing computer 150 described herein. For example, the computer-readable medium 156 can include a tokenization module 156A, a detokenization module 156B, a lookup module 156C, and a management module 156D. The processing computer 150 can also include a trusted list item database 154.

[0077] The processor 151 can be implemented as one or more integrated circuits (e.g., one or more single-core or multi-core microprocessors and / or microcontrollers). The processor 151 can be used to control the operation of the processing computer 150. The processor 151 can execute a variety of programs in response to program code or computer-readable code stored in the memory 153. The processor 151 can include functionality to maintain multiple concurrently executing programs or processes.

[0078] The network interface 152 can be configured to connect to one or more communication networks to allow the processing computer 150 to communicate with other entities, such as the transport computer 140, the authorization entity computer 170, the directory server computer 160, etc. For example, the communication with the authorization entity computer 170 can be direct, indirect, and / or through an API.

[0079] The memory 153 can be implemented using any combination of any number of nonvolatile memory (e.g., flash memory) and volatile memory (e.g., DRAM, SRAM), or any other non-transitory storage medium or combination of media.

[0080] The computer-readable medium 156 can include one or more non-transitory media used to store and / or transport data. Suitable media include, for example, random access memory (RAM), read only memory (ROM), magnetic media, such as a hard disk drive, or optical media, such as a compact disc (CD) or DVD (digital versatile disc), flash memory, etc. The computer-readable medium 156 can be any combination of such storage or transport mechanisms.

[0081] The tokenization module 156A, in conjunction with the processor 151, can generate tokens for account information, such as credentials. The tokenization module 156A, in conjunction with the processor 151, can generate tokens in response to a token request message from a resource provider. Some tokens can be payment tokens that are based on payment credentials. If the resource provider is a trusted list item, the token can be a trusted list item token and can include a trusted flag to indicate to other entities, such as an authorization entity, that the resource provider is trusted.

[0082] The detokenization module 156B, in conjunction with the processor 151, can map the token to account information associated with the token. For example, the detokenization module 156B, in conjunction with the processor 151, can map the token from the user to the user's PAN.

[0083] The lookup module 156C, in conjunction with the processor 151, can query the trusted listing database 154. By querying the trusted listing database, the lookup module 156C, in conjunction with the processor 151, can determine whether there is data indicating that the resource provider is trusted. The lookup module 156C, in conjunction with the processor 151, can query the trusted listing database 154 using the user identifier or the account identifier. The lookup module 156C can then receive data from the trusted listing database 154 indicating that the resource provider is trusted by the user. Such data can include, for example, a flag, a date the trusted listing was established, a trusted indicia, or some other data field.

[0084] The management module 156D, in conjunction with the processor 151, can manage the trusted listings. The management module 156D, in conjunction with the processor 151, can change or remove the trusted listing status of a resource provider. The management module 156D can receive instructions from the user or from the ACS (e.g., from the issuer) to update or remove a trusted listing in the trusted listing database 154. Additionally or alternatively, the management module 156D, in conjunction with the processor 151, can periodically remove the trusted listing status of a resource provider to force re-authentication of the user. If the user receives a new user identifier or account identifier, the management module 156D, in conjunction with the processor 151, can transfer the trusted listing associated with the previous identifier to the new identifier.

[0085] The trusted listing database 154 can store trusted listing information for users and resource providers. The trusted listing database 154 can store resource provider identifiers for resource providers trusted by the user and user identifiers for users who trust each resource provider. Additionally or alternatively, the trusted listing database 154 can store account identifiers for users. The trusted listing database 154 can also store data indicating that a resource provider is trusted (e.g., a trusted indicia, a trusted listing token, a password). The trusted listing database 154 can also store a time of establishment of the trusted listing status and a time of removal of the trusted listing status. For example, the date the trusted listing was created can be used to re-authenticate the trusted listing in the trusted listing database after one year. In some embodiments, the trusted listing database 154 can be shared between the processing computer 150 and the directory server computer 160, or can be associated with the directory server computer 160.

[0086] Figure 4A swim lane diagram showing enrollment of a resource provider as a trusted list item for a user, according to an embodiment. In some embodiments, the enrollment can occur during a transaction. In other embodiments, the enrollment can occur as a separate interaction from a transaction.

[0087] In step S402, the user can initiate enrollment of the resource provider using the user device 120. In some embodiments, the enrollment can be part of a 3DS enrollment or a secure remote commerce (SRC) enrollment process, for example. The user device 120 can send an account identifier (e.g., PAN, token, credential) to the resource provider computer 130. Additionally or alternatively, the user device 120 can send a user identifier (e.g., code, phone number) that can be mapped to the account identifier. In some embodiments, the resource provider computer 130 can request a trusted list item status from the user during a transaction. For example, the resource provider computer 130 can request the trusted list item status by sending a message to the user device 120 during a transaction. The user device 120 can display the message, such as "Would you like to consider Joe's Clothes as a trusted merchant for future transactions?" The user can choose to accept or not accept the trusted list item request. If the user chooses not to accept the trusted list item request, the enrollment process can end. If the user accepts the trusted list item request, the enrollment process can continue. Prior to requesting the trusted list item status, the resource provider computer 130 can verify that the user is able to have a trusted list item. A plug-in 135 of the resource provider computer 130 can be invoked, and the plug-in 135 can determine that the user is able to have a trusted list item. For example, a transaction message can include an authorization entity eligibility flag to indicate whether / when the resource provider computer 130 can request the user to enroll based on the user's authorization entity. In some embodiments, the user can agree to have a credential (e.g., payment credential) additionally stored by the resource provider computer 130.

[0088] In some embodiments, the resource provider computer 130 can obtain a token (e.g., payment token) of the user during an interaction. The resource provider computer 130 can obtain the token through a standard process. For example, the user can send the token from the user device 120 to the resource provider computer 130. Alternatively, the resource provider computer 130 can request the token from a token service system.

[0089] In step S404, the resource provider computer 130 can invoke the plug-in 135 to generate a trusted list item request flag. The trusted list item request flag can indicate that the resource provider is trusted by the user and that the resource provider computer 130 is requesting a trusted list item status. In some embodiments, the resource provider computer 130 can initiate an authentication process and receive CAVV (card authentication verification value) data that can be subsequently passed to the plug-in 135.

[0090] In step S406, the plug-in 135 can generate a trusted list item request message. The trusted list item request message can include a trusted list item request flag, a resource provider identifier, an account identifier, and / or a user identifier. The plug-in 135 can then send the trusted list item request message to the directory server computer 160.

[0091] In embodiments, the trusted list item request message can be part of other transaction messages. In some embodiments, the trusted list item request message can be a strong authentication request message (e.g., a 3D Secure message) that includes a trusted list item request flag. In other embodiments, the trusted list item request message can be part of a token request message. For example, the plug-in 135 can submit a token request message to the directory server computer 160 that includes a trusted list item request flag. Alternatively, the token request message can be sent to the authorizing entity computer 170 or the processing computer 150. In other embodiments, the trusted list item request message can be part of a stored credential transaction message. For example, the plug-in 135 can submit a credential establishment transaction message that requests the rights to store a user's credential. In addition to an establishment stored credential request flag (e.g., a POS environment field of 'C'), the credential establishment transaction message can also include a trusted list item request flag. The credential establishment transaction message can be an account verification if the user is not charged, or a payment transaction if a charge is involved.

[0092] In embodiments, the transaction message can also include a CAVV (card authentication verification value), a TAVV (transaction authentication verification value), and a MVV (merchant verification value). The CAVV can be a cryptogram that establishes that the user has been authenticated for the transaction. The TAVV can be a cryptogram that accompanies a token that restricts the token to a particular domain. The MVV can be a value that indicates that the resource provider has been verified and / or is participating in a particular program. For example, the MVV can be "05" indicating that the resource provider is able to become a trusted list item. The MVV can also depend on the type of resource provider. For example, an airline and a coffee shop can have different resource provider types, and thus have different MVVs even if they are in the same program.

[0093] In step S408, the directory server computer 160 can receive the trusted list item request message. The directory server computer 160 can then determine whether the resource provider has been trusted by the user by determining whether data indicating that the resource provider is trusted already exists in the trusted list item database. The directory server computer 160 can query the trusted list item database using the resource provider identifier and the account identifier (or user identifier). The directory server computer 160 can communicate with the processing computer 150 to query the trusted list item database. If the directory server computer 160 receives a token from the resource provider computer, the directory server computer 160 can map the token of the user to the account identifier (e.g., PAN). The authorization entity computer 170 can then use the account identifier to identify the account associated with the user. The directory server computer 160 can also communicate with the processing computer 150 to map the token to the account identifier.

[0094] In step S410, the directory server computer 160 can provide first level authentication for the user. The first level can be a strong authentication of the user. In some embodiments, the directory server computer 160 can directly authenticate the user. In other embodiments, the directory server computer 160 can send the trusted list item request message to the ACS 175, and the ACS 175 can authenticate the user. The directory server computer 160 can send the trusted list item request message to the ACS 175 through the authorization entity computer 170. The trusted list item request message can include the account identifier, the resource provider identifier, and a trusted list item request flag. In some embodiments, the directory server computer 160 can include a CVM indicator in the trusted list item request message based on a CVM (cardholder verification method). For example, the resource provider can have first authenticated the user at the beginning of the interaction by requesting a PIN. The directory server computer 160 can then include the CVM indicator to indicate that a PIN was used.

[0095] At step S412, ACS 175 can perform a first level authentication of the user. Authorization entity computer 170 can send an authentication request to ACS 175. The strong authentication request can include an account identifier, a resource provider identifier, a trusted list item request flag, and a status. ACS 175 can then issue a challenge to the user through user device 120. For example, ACS 175 can send a request for a password (e.g., a one-time password) to user device 120. The user can indicate that he or she does not recognize the resource provider and / or the trusted list item request and cancel the enrollment process. In some embodiments, authorization entity computer 170 can authenticate the user using an existing strong authentication process (e.g., 3D Secure). The trusted list item request flag in the strong authentication message can indicate that step-up authentication is required. In some embodiments, authorization entity computer 170 can approve or deny the trusted list item request prior to requesting authentication of the user. For example, the resource provider associated with the trusted list item request can have a history of submitting fraudulent trusted list item request messages.

[0096] At step S414, after authenticating the user, authorization entity computer 170 can send a trusted list item response message to directory server computer 160. The trusted list item response message can include an indication that the user has been authenticated (e.g., cryptogram, CAVV) and a trusted flag. The trusted list item response message can also include a transaction status, an electronic commerce indicator (ECI), and a CAVV.

[0097] At step S416, directory server computer 160 can communicate the trusted flag to processing computer 150. Processing computer 150 can store data indicating that the resource provider is trusted by the user in a trusted list item database. Such data can include, for example, a flag, a date that the trusted list item was established, the trusted flag, or some other data field. Processing computer 150 can store the account identifier and the resource provider identifier, and optionally the user identifier, in the trusted list item database. Processing computer 150 can also store the trusted flag and / or an indication that the user was authenticated in the trusted list item database. In some embodiments, a trusted list item token can be generated using the trusted flag. The strong authentication service provider can then retrieve the trusted list item token.

[0098] In step S418, the directory server computer 160 can send a trusted list item response message to the resource provider computer 130. The trusted list item response message can indicate to the resource provider that the trusted list item was successfully created and that the user was authenticated at the first level of authentication. In some embodiments, if the resource provider sends a credential establishment transaction message, the resource provider computer 130 can store an account identifier for the user account, such as an account credential, for future stored credential transactions. Additionally, the directory server computer 160 can return a trusted flag to the resource provider's acquirer to indicate successful creation of the trusted list item. In some embodiments, the resource provider computer 130 can retrieve the trusted list item token. The trusted flag can also indicate to the acquirer the successful establishment of a stored credential. The resource provider computer 130 can maintain a list of users that trust the resource provider.

[0099] In some embodiments, the indication that a resource provider is trusted by a user is received from the authorization entity computer 170. For example, a user can initiate an enrollment through an issuer website or mobile application associated with the authorization entity. The user can provide an account identifier and / or a user identifier to the authorization entity computer 170 and select a resource provider that the user wants to trust. In some embodiments, the authorization entity computer 170 can map the user identifier to the account identifier. The authorization entity computer 170 can then generate a trusted list item request message that includes the account identifier and the resource provider identifier. The user can have previously self-authenticated to the authorization entity computer 170, such as to access the issuer website, so the trusted list item request message can also include an indication that the user is authenticated. If the directory server computer 160 receives the trusted list item request message from the authorization entity computer 170, the directory server computer 160 can not request authentication of the user from the authorization entity computer 170.

[0100] Figure 5 A swim lane diagram showing subsequent authorization of a transaction with a trusted resource provider. For example, if the enrollment process of the user with the resource provider is part of the transaction, the authorization process can occur directly after the enrollment process. Figure 4 If the enrollment process of the user with the resource provider is part of the transaction, the authorization process can occur directly after the enrollment process.

[0101] In step S502, resource provider computer 130 can send an authorization request message to transport computer 140. Transport computer 140 can be operated by a resource provider's acquirer. The authorization request message can include a trusted marker, a user identifier, a resource provider identifier, and transaction information (e.g., transaction amount, timestamp). The authorization request message can be sent by a plug-in of resource provider computer 130. In some embodiments, the authorization request message can include a user's trusted listing token and / or a cryptogram with a trusted marker. In some embodiments, the resource provider can submit a subsequent stored credential transaction message. The stored credential transaction message can include fields for TAVV and POS input mode 10 (stored credential transaction). The authorization request message can additionally include an electronic commerce indicator (ECI) and a CAVV.

[0102] In step S504, transport computer 140 can send the authorization request message to processing computer 150. Processing computer 150 can be part of a payment processing network.

[0103] In step S506, processing computer 150 can verify the trusted marker from resource provider computer 130. Processing computer 150 can query a trusted listing database using the resource provider identifier and the account identifier and determine that there is data indicating that the resource provider is trusted. Processing computer 150 can use the data to verify the trusted marker to form a verified trusted marker. Processing computer 150 can add the verified trusted marker to the authorization request message. Additionally or alternatively, processing computer 150 can add a flag to the authorization request message indicating that the trusted marker is valid. The flag and / or the verified trusted marker can have been added during a previous authentication process, such as the process of FIG. 1. Figure 4 The flag can depend on the MVV. For example, the resource provider can be required to have a particular MVV indicating that the resource provider is able to be a trusted listing. Additionally or alternatively, the flag can depend on the MVV having a value associated with a particular resource provider type. For example, the requirements for a trusted listing for an airline can be different than the requirements for a trusted listing for a coffee shop. Based on the CVM, processing computer 150 can include a CVM indicator in the authorization request message. For example, the resource provider can have first verified the user at the beginning of the interaction by requesting a PIN. Processing computer 150 can then include the CVM indicator to indicate that a PIN was used. In some embodiments, for a transaction using a token, processing computer 150 can check the TAVV and the user's trusted listing status with the token and the resource provider identifier as part of token processing.

[0104] In step S508, the processing computer 150 can send an authorization request message to the authorization entity computer 170. In addition to including transaction information (e.g., transaction amount, timestamp), a user identifier, and a resource provider identifier, the authorization request message can include a flag indicating that the trusted marker is valid and / or that the trusted marker has been verified.

[0105] In step S510, the authorization entity computer 170 can receive the authorization request message and process the transaction. The authorization entity computer 170 can approve or deny the authorization request. The authorization entity computer 170 is more likely to approve an authorization request with a trusted marker, as this can indicate that the transaction is low risk. Even if the resource provider is trusted by the user, the authorization entity computer can still deny the authorization request, for example, due to potential fraud indicators. For example, the transaction can be for a higher than usual amount (e.g., $1000 instead of $20) or can originate from an unusual location. The authorization entity computer 170 can then generate an authorization response message including an authorization decision (e.g., approval, denial). The authorization entity computer 170 can then send the authorization response message to the processing computer 150.

[0106] In step S512, the processing computer 150 can send the authorization response message to the transport computer 140, which can then send the authorization response message to the resource provider computer 130. If the authorization is denied, the resource provider computer 130 can choose to reattempt the transaction. The resource provider can be advised to request additional user authentication, which can include strong authentication (e.g., relative to Figure 4 described).

[0107] In some embodiments, prior to transaction processing, the resource provider computer 130 can verify the status of the trusted list item cryptographically. During a transaction with the user, the resource provider computer 130 can request a cryptogram from the processing computer 150 using a plug-in. If the resource provider is trusted by the user, the resource provider computer 130 can receive a cryptogram with a trusted marker. If the resource provider is not trusted, the resource provider computer 130 can be directed to a strong authentication process (e.g., relative to Figure 4 described). In other embodiments, the resource provider computer 130 can submit an account verification / file query message prior to submitting a stored credential transaction message to determine whether the resource provider is trusted by the user.

[0108] Figure 6 Authentication and authorization of interactions between a user and a resource provider trusted by the user after enrollment are shown. Subsequent interactions between the user and the resource provider can utilize the trusted list item.

[0109] In step S602, the user can initiate a transaction with a resource provider using the user device 120. The user device 120 can send an account identifier (e.g., PAN, token, credential) to the resource provider computer 130. Additionally or alternatively, the user device 120 can send a user identifier (e.g., code, phone number) that can be mapped to an account identifier.

[0110] In step S604, the resource provider computer 130 can send an authentication request message including a resource provider identifier and an account identifier to the directory server computer 160. The authentication request message can be sent by the plug-in 135 of the resource provider computer 130. The authentication request message can include a trusted flag. The authentication request message can also include additional data, such as a verification value (e.g., CAVV, TAVV). If the user device 120 provided a user identifier, and the user has stored a credential (e.g., PAN, account number) with the resource provider, the resource provider computer 130 can map the user identifier to the account identifier (e.g., stored credential). In some embodiments, the resource provider computer 130 can request a token, and can receive a trusted listing token.

[0111] In step S606, the directory server computer 160 can verify that the resource provider is trusted by the user. The directory server computer 160 can query the trusted listing database using the resource provider identifier and the account identifier (or user identifier) and determine that there is data indicating that the resource provider is trusted. Such data can include, for example, a flag, a date that the trusted listing was established, a trusted flag, or some other data field. The directory server computer 160 can communicate with the processing computer 150 to query the trusted listing database. If the authentication request message includes a trusted flag, the directory server computer 160 can verify that the resource provider is trusted by the user by verifying the trusted flag. The directory server computer 160 can verify the trusted flag by querying the trusted listing database for data indicating that the resource provider is trusted by the user. After verifying that the resource provider is trusted by the user, the directory server computer 160 can then add a verified trusted flag to the authentication request message. The trusted flag can be verified by signing the trusted flag with a secret key maintained by the directory server. Additionally or alternatively, the directory server computer 160 can add a flag to the authentication request message indicating that the trusted flag is valid.

[0112] In step S608, the directory server computer 160 can provide a second level of authentication for the user. In some embodiments, the directory server computer 160 can directly authenticate the user and generate an authorization response message indicating that the user has been authenticated. In other embodiments, the directory server computer 160 can send an authentication request message with a verified trusted flag to the ACS 175. If the ACS 175 receives an authentication request with a verified trusted flag, the ACS 175 can challenge the user using a second level of authentication. The second level of authentication can be less than the first level of authentication. For example, if the first level of authentication involves challenging the user for a password, the second level of authentication can involve the ACS 175 collecting device data from the user device 120. The second level of authentication can also be no authentication. Based on the authentication result, the ACS 175 can generate a verified trusted flag and can generate an authentication response message indicating that the user has been authenticated.

[0113] In step S610, the directory server computer 160 can send an authentication response message to the resource provider computer 130 indicating that the user has been authenticated. The authentication response message can indicate to the resource provider that the user has been authenticated at the second level of authentication. The authentication response message can also include the verified trusted flag. The authorization response message can be sent through the plug-in 135.

[0114] In step S612, the resource provider computer 130 can send an authorization request message to the transport computer 140. The transport computer 140 can be operated by the resource provider's acquirer. The authorization request message can include the verified trusted flag, the user identifier, the resource provider identifier, and transaction information (e.g., transaction amount, timestamp). The authorization request message can be sent by the plug-in 135. In some embodiments, the authorization request message can include the user's trusted list entry token and / or the cryptogram with trusted flag. In other embodiments, the resource provider can submit a subsequent stored credential transaction message. The stored credential transaction message can include fields for TAVV and POS input mode 10 (stored credential transaction). The authorization request message can additionally include an electronic commerce indicator (ECI) and a CAVV.

[0115] In step S614, the transport computer 140 can send the authorization request message to the processing computer 150. The processing computer 150 can be part of a payment processing network.

[0116] In step S616, processing computer 150 can verify the trusted marker from resource provider computer 130. If the trusted marker is a verified trusted marker, processing computer 150 can decrypt the verified trusted marker. If the trusted marker is not a verified trusted marker, processing computer 150 can use the resource provider identifier and the account identifier to query the trusted listing database and determine that there is data indicating that the resource provider is trusted. Processing computer 150 can add the verified trusted marker to the authorization request message after verifying that the resource provider is trusted by the user. Additionally or alternatively, processing computer 150 can add a flag to the authorization request message indicating that the trusted marker is valid. The flag can be added to the authorization request message by processing computer 150 in addition to the verification done by directory server computer 160. The flag added by processing computer 150 can also depend on the MVV. For example, the resource provider can need to have a particular MVV that indicates that the resource provider is able to be a trusted listing. Additionally or alternatively, the flag can depend on the MVV having a value associated with a particular resource provider type. For example, the requirements for a trusted listing for an airline can be different than the requirements for a trusted listing for a coffee shop. The flag and / or the verified trusted marker can have been added during a previous authentication process. Based on the CVM, processing computer 150 can include a CVM indicator in the authorization request message. For example, the resource provider can have first verified the user at the beginning of the interaction by requesting a PIN. Processing computer 150 can then include the CVM indicator to indicate that a PIN was used. In some embodiments, processing computer 150 can check the TAVV and the user's trusted listing status with the token and resource provider identifier as part of token processing.

[0117] In step S618, processing computer 150 can send the authorization request message to authorization entity computer 170. In addition to including transaction information (e.g., transaction amount, timestamp), a user identifier, and a resource provider identifier, the authorization request message can include a flag indicating that the trusted marker is valid and / or a verified trusted marker.

[0118] In step S620, the authorization entity computer 170 can receive the authorization request message and process the transaction. The authorization entity computer 170 can approve or deny the authorization request. The authorization entity computer 170 is more likely to approve an authorization request with a trusted listing, as this can indicate a low risk transaction. Even if the resource provider is trusted by the user, the authorization entity computer can still deny the authorization request, for example, due to potential fraud indicators. For example, the transaction can be for a higher than usual amount (e.g., $1000 instead of $20) or can originate from an unusual location. The authorization entity computer 170 can then generate an authorization response message including the authorization decision (e.g., approval, denial). The authorization entity computer 170 can then send the authorization response message to the processing computer 150.

[0119] In step S622, the processing computer 150 can send the authorization response message to the transport computer 140, which can then send the authorization response message to the resource provider computer 130. If the authorization is denied, the resource provider computer 130 can choose to reattempt the transaction. The resource provider can be advised to request additional user authentication, which can include strong authentication (e.g., 3DS authentication).

[0120] In some embodiments, even if the resource provider is a trusted listing item for the user, the resource provider can be able to request additional authentication of the user in subsequent transactions. For example, for high value transactions (e.g., any transaction over $1000) and / or high volume transactions (e.g., more than three transactions from the same user in a day), the resource provider can require strong authentication. The resource provider can request strong authentication by not including the trusted listing flag in the authentication request message. Additionally or alternatively, the resource provider can include a flag in the authentication request message indicating that additional authentication is requested. The user can then be authenticated at a first level of authentication or at some level of authentication higher than the second level of authentication.

[0121] As detailed above, embodiments of the present application can integrate with a variety of existing transaction and authentication systems including 3D Secure, Secure Remote Commerce (SRC), and stored credential transaction processes to provide the advantages of a trusted listing item. Embodiments can use a trusted listing request flag in a strong authentication message to indicate a trusted listing request and force stepped up authentication. A strong authentication service provider can integrate with a token service system such as Visa Token Service to retrieve a trusted listing token upon completion of strong authentication. SRC can allow a resource provider to deploy tokenization broadly on their stored credentials. When a user initiates a transaction, the token can become a trusted listing token, thereby efficiently converting tokens without requiring additional computing resources. A resource provider can have a combination of SRC tokens and trusted listing tokens. The SRC token itself can not qualify for the exemption of strong authentication requirements and can need to be authenticated or qualify for other exemption options (low value, low risk).

[0122] After a resource provider is established as a trusted list item for a user, an entity such as the user, ACS, or authorized entity can manage the trusted list item status and / or account identifier associated with the trusted list item. For example, after a PAN is replaced as part of credential lifecycle management, the ACS can update the PAN associated with the user in the trusted list item that the user has. As another example, if a trusted relationship with a resource provider is no longer requested, the user and / or ACS can delete the trusted list item. If the trusted list item status is removed from a token, the token can be downgraded (e.g., to a standard SRC token) and can no longer qualify for the trusted list item exemption for strong authentication.

[0123] In some embodiments, trusted list item management can be initiated by the user. For example, a user can be able to manage the user's trusted list items through a website or mobile application associated with an authorized entity computer (e.g., an authorized entity computer operated by an issuer), such as an issuer website. The issuer site can display a list of resource providers trusted by the user and can provide options for managing the trusted list item status for each resource provider. The options can include removing the trusted list item status, updating the account identifier associated with the trusted list item, and adding a new resource provider as a trusted list item.

[0124] In one embodiment of user-initiated trusted list item management, a user can first access an issuer site operated by an issuer through an authorized entity computer. The user can authenticate themselves to the issuer site by any suitable method. For example, the user can enter a password and / or a biometric measurement. The user can also be required to submit an account identifier (e.g., a PAN, account number) or a user identifier (e.g., a phone number). In some embodiments, the authorized entity computer can use the user identifier to retrieve the user's account identifier, such as a PAN. The user can then access a list of trusted resource providers and / or resource providers that can be added as a trusted list item. The user can indicate the trusted list item status changes that it would like to make. For example, the user can indicate that it would like to remove the trusted list item status for Joe's Clothes. The authorized entity computer can then generate a trusted list item status update message to add or remove the trusted list item status for a resource provider. The trusted list item status update request can include an account identifier or user identifier, a resource provider identifier for the selected resource provider, and an indicator of the desired trusted list item status change.

[0125] The authorized entity computer can then submit the trusted list item status update message to a processing computer. Alternatively, the trusted list item status update message can be sent to a directory server.

[0126] The processing computer can then update the trusted list item database with the trusted list item status change. The processing computer can query the trusted list item database using the user identifier and / or account identifier and the resource provider identifier. The processing computer can then send a confirmation message to the authorized entity computer indicating that the desired trusted list item status update has been made. The issuer can then communicate the trusted list item status change to the user through the issuer site.

[0127] In other embodiments, trusted list item management can be initiated directly by the authentication entity (e.g., ACS, authorized entity, issuer). For example, an issuer can send a trusted list item status update to the processing computer to remove all trusted list item status for a resource provider that has been found to be fraudulent. The authentication entity can also periodically remove trusted list item status for a resource provider (e.g., after one year) to ensure that the trusted list items remain up to date. In some systems that have deployed tokenization, the authentication entity can have deployed token lifecycle management APIs. These token lifecycle management APIs can also be used to manage trusted list item tokens. Alternative lifecycle management options can be available for authentication entities that have not deployed tokenization, such as through a strong authentication service provider deploying lifecycle management. Lifecycle management of the credentials associated with trusted list items can be facilitated through the payment processing network.

[0128] Figures 7A-7C A set of screenshots showing a process to add a resource provider as a trusted list item during a transaction according to an embodiment. Figure 7A A set of screenshots are shown on a resource provider site. The resource provider site can display a prompt for the user to add the resource provider as a trusted list item. The trusted list item prompt can occur after the user enters payment information such as a payment credential or token. As Figure 7B The user can then be directed to the issuer site as depicted in Figure 7C The user can be required to authenticate themselves, for example, by entering a fingerprint for biometric authentication. The user can be able to confirm that they wish to add the resource provider as a trusted list item. The user can also complete the transaction payment at the issuer site. The user can then be directed back to the resource provider site as depicted in

[0129] Figure 8 A screenshot of a resource provider site according to an embodiment is shown. The resource provider site can be Figure 7AThe resource provider site can display a prompt for the resource provider to request to be added as a trusted list item. The resource provider site can also allow the user to select whether or not they wish to trust the resource provider. For example, there can be a radio button 810 to select between adding the resource provider as a trusted list item and not adding the resource provider as a trusted list item. In other embodiments, there can be a slider, drop down list, or check box to select to add the resource provider as a trusted list item. There can also be information about the trusted list item process, including the benefits to the user. The resource provider site can provide a way to access additional information about the trusted list item. For example, there can be a link 820 to a website with additional information.

[0130] Figure 9 A screenshot of an issuer site used in trusted list item management according to an embodiment is shown. A user can access the issuer site after authenticating themselves. The issuer site can show a list of resource providers trusted by the user 910. The list 910 can show the identifying data for each trusted resource provider, such as the name or logo of the resource provider. Selecting a resource provider from the list 910 can open additional information and options for the trusted list item. The issuer site can also present an option to remove a resource provider as a trusted list item 920. The issuer site can also present a list of other eligible resource providers to add as a trusted list item 930. Selecting a resource provider from the list of recommendations 930 can initiate enrollment for that resource provider.

[0131] Embodiments of the invention provide several advantages. By reducing the authentication level for resource providers that are trusted list items, fewer authentication process steps can be performed, particularly fewer authentication steps involving the user, compared to authenticating the user at a high level each time a transaction is made. This can save computing resources and processing power.

[0132] Coupling trusted list items with a stored credential transaction framework can provide additional advantages. Embodiments can support trusted list items for SRCs as well as stored credential resource providers, and can not require new integration work to existing token service systems. Embodiments can enable an authorizing entity to easily manage trusted list items, for example, through existing token lifecycle management APIs or file updates to ISO messages, and can enable resource providers to verify trusted list item status using existing ISO messages and / or enhanced token service APIs.

[0133] Embodiments of the invention can be built on top of token processing, which can be complex for transactions that are not handled by a proprietary processing computer. Some systems have established token interchange to support interoperability. Authorizing entity participation can be optional, but can be supported by using existing strong authentication processing as the primary method of implementation and support.

[0134] Any of the software components or functions described in this application can be implemented as software code to be executed by a processor using any suitable computer language such as, for example, Java, C++, or Perl using, for example, conventional or object-oriented techniques. The software code can be stored as a series of instructions or commands on a computer readable medium such as a random access memory (RAM), a read-only memory (ROM), a magnetic medium such as a hard-drive or optical medium on a CD-ROM, etc. Any such computer readable medium can reside on or within a single computational device or external data storage device, and can be present on or within different computational devices or external data storage devices at the same time.

[0135] The above description is illustrative and not restrictive. Many variations of the application will become apparent to those of skill in the art upon review of this disclosure. The scope of the application should, therefore, be determined not with reference to the above description, but instead with reference to the appended claims along with their full scope or equivalents.

[0136] One or more features of any embodiment can be combined with one or more features of any other embodiment, without departing from the scope of the application.

[0137] The recitation "a" or "said" is intended to mean "one or more" unless specifically indicated to the contrary.

[0138] All patents, patent applications, publications, and descriptions mentioned above are herein incorporated by reference in their entirety for all purposes. None is admitted to be prior art.

Claims

1. An authentication method comprising: receiving, by a directory server computer, an authentication request message from a user interacting at a resource provider computer operated by a resource provider; determining, by the directory server computer, that data indicative of the user trusting the resource provider is present in a database, the data comprising a trusted indicia; in response to determining that the data comprising the trusted indicia is present, providing, by the directory server computer, authentication to the user for the interaction; sending, by the directory server computer, information indicative of the user having been authenticated and the trusted indicia to the resource provider computer; receiving, by a processing computer, an authorization request message for the interaction from the resource provider computer, the authorization request message comprising the trusted indicia received by the resource provider computer from the directory server computer; verifying, by the processing computer, the trusted indicia; and sending, by the processing computer, the authorization request message to an authorization entity computer, the authorization request message comprising information related to the interaction and the verified trusted indicia.

2. The authentication method of claim 1, wherein the resource provider computer stores an account identifier for an account of the user.

3. The authentication method of claim 2, wherein the interaction is a stored credential transaction.

4. The authentication method of claim 1, wherein the authentication request message comprises a resource provider identifier for the resource provider and a verification value for the user.

5. The authentication method of claim 1, wherein the indication that the resource provider is trusted is received from the resource provider computer.

6. The authentication method of claim 1, wherein the indication that the resource provider is trusted is received from the authorization entity computer.

7. An authentication method comprising: receiving, by a resource provider computer operated by a resource provider, a trusted listing item response message from a directory server computer, the trusted listing item response message indicating that a trusted listing item has been created and that a user has been authenticated and comprising a trusted indicia; sending, by the resource provider computer, an authentication request message to the directory server computer for an interaction by a user at the resource provider computer, the authentication request message comprising the trusted indicia; receiving, by the resource provider computer, an authentication response message from the directory server computer, the authentication response message indicating that the user is authenticated for the interaction; and sending, by the resource provider computer, an authorization request message for the interaction to a processing computer, the authorization request message comprising the trusted indicia, wherein the processing computer is configured to verify the trusted indicia and send the authorization request message to an authorization entity computer comprising information related to the interaction and the verified trusted indicia.

8. The authentication method of claim 7, wherein the trusted listing item response message comprises a token.

9. An authentication method comprising: ​ receiving, by a processing computer from a directory server computer, a message including an indication that a user has been authenticated and a trusted indicia representing that a resource provider is trusted by the user, wherein the authentication is provided to the user as part of registering the resource provider as trusted by the user; storing, by the processing computer, the trusted indicia in a database; receiving, by the processing computer, an authorization request message for an interaction between the user and a resource provider computer operated by the resource provider, the authorization request message including an indication that the user has been authenticated for the interaction and the trusted indicia; determining, by the processing computer, that the trusted indicia exists in the database; in response to determining that the trusted indicia exists, verifying, by the processing computer, the trusted indicia; and sending, by the processing computer to an authorization entity computer, the authorization request message including information related to the interaction and the verified trusted indicia.

10. The authentication method of claim 9, wherein verifying the trusted indicia includes: querying the database; and determining that the trusted indicia has been previously stored in the database.

11. An authentication system comprising one or more computer systems configured to perform the authentication method of any of claims 1 to 10.

12. A directory server computer comprising: a processor; and a computer readable medium coupled to the processor, the computer readable medium comprising code, which when executed by the processor, causes the processor to perform a method comprising: receiving an authentication request message from a user interacting at a resource provider computer operated by a resource provider; determining that data representing an indication that the user trusts the resource provider exists in a database, the data including a trusted indicia; in response to determining that the data including the trusted indicia exists, providing authentication to the user for the interaction; and sending information indicating that the user has been authenticated and the trusted indicia to the resource provider computer; wherein: the resource provider computer sends an authorization request message for the interaction to a processing computer, the authorization request message including the trusted indicia received by the resource provider computer from the directory server computer, and the processing computer verifies the trusted indicia and sends the authorization request message to an authorization entity computer, the authorization request message including information related to the interaction and the verified trusted indicia.

13. The directory server computer of claim 12, wherein the resource provider computer stores an account identifier for an account of the user.

14. The directory server computer of claim 13, wherein the interaction is a stored credential transaction.

15. The directory server computer of claim 12, wherein the authentication request message includes a resource provider identifier for the resource provider and a verification value for the user. ​ ​ 16. The directory server computer of claim 12, wherein the indication that the resource provider is trusted is received from the resource provider computer.

17. The directory server computer of claim 12, wherein the indication that the resource provider is trusted is received from the authorization entity computer.

18. A resource provider computer operated by a resource provider, the resource provider computer comprising: a processor; and a computer-readable medium coupled to the processor, the computer-readable medium comprising code, which, when executed by the processor, causes the processor to implement a method comprising: receiving a trusted listing item response message from a directory server computer, the trusted listing item response message indicating that a trusted listing item has been created and that a user has been authenticated and including a trusted flag; sending an authentication request message to the directory server computer regarding an interaction by the user at the resource provider computer, the authentication request message including the trusted flag; receiving an authentication response message from the directory server computer, the authentication response message indicating that the user is authenticated with respect to the interaction; and sending an authorization request message for the interaction to a processing computer, the authorization request message including the trusted flag, wherein the processing computer is configured to verify the trusted flag and to send the authorization request message including information related to the interaction and the verified trusted flag to an authorization entity computer.

19. The resource provider computer of claim 18, wherein the trusted listing item response message includes a token.

20. A processing computer comprising: a processor; and a computer-readable medium coupled to the processor, the computer-readable medium comprising code, which, when executed by the processor, causes the processor to implement a method comprising: receiving a message from a directory server computer, the message including an indication that a user has been authenticated and a trusted flag representing that a resource provider is trusted by the user, wherein the authentication is provided to the user as part of registering the resource provider as trusted by the user; storing the trusted flag in a database; receiving an authorization request message for an interaction between the user and a resource provider computer operated by the resource provider, the authorization request message including an indication that the user has been authenticated with respect to the interaction and the trusted flag; determining that the trusted flag exists in the database; in response to determining that the trusted flag exists, verifying the trusted flag; and sending the authorization request message to an authorization entity computer, the authorization request message including information related to the interaction and the verified trusted flag. ​ ​ ​

Images