EP4655919A1

EP4655919A1 - Trusted authentication context

Info

Publication number: EP4655919A1
Application number: EP24747738.3A
Authority: EP
Inventors: Ranjiva PRASAD; Bharatesh PAI; David Wilson; Kerry HEBERT
Original assignee: Visa International Service Association
Current assignee: Visa International Service Association
Priority date: 2023-01-25
Filing date: 2024-01-24
Publication date: 2025-12-03
Also published as: EP4655919A4; CN120584474A; WO2024158895A1

Abstract

A method is disclosed. The method includes receiving authentication result data associated with an authentication request initiated by an orchestrator computer and performed using a credential of a user. The authentication request can be in response to the user initiating a first process. The method also includes receiving, from a data processor computer, an authentication context request message associated with the credential. The authentication context request message can be in response to an initiation of a second process different than the first process. The method can also comprise performing a search for the authentication result data using the credential and transmitting the authentication result data or a derivative thereof to the data processor computer. The data processor computer analyzes the authentication result data or the derivative thereof and decides to perform the second process based on the authentication result data or the derivative thereof.

Description

TRUSTED AUTHENTICATION CONTEXT

CROSS-REFERENCES TO RELATED APPLICATIONS

[0001] This application is a PCT application which claims priority to U.S. Provisional Application No. 63/481 ,574, filed on Jan. 25, 2023, which is herein incorporated by reference in its entirety.

BACKGROUND

[0002] If a user wants to use a service offered by a service provider, the user needs to authenticate themselves to the service provider. The user can use a secret (e.g., a password or PIN) or other authentication data to authentication themselves to the service before the service provider provides the service to the user. If the user wants to receive multiple services provided by multiple different service providers, then the user needs to authenticate themselves to each of the service providers, typically in separate online sessions. This is cumbersome for the user, and it would be desirable to reduce the number of steps associated with authenticating a user to multiple services.

[0003] Embodiments of the disclosure address this problem and other problems individually and collectively.

BRIEF SUMMARY

[0004] One embodiment of the invention includes a method. The method comprises: receiving, by an authentication context registry server, authentication result data associated with an authentication request initiated by an orchestrator computer and performed using a credential of a user, the authentication request being in response to the user initiating a first process; receiving, by the authentication context registry server from a data processor computer, an authentication context request message associated with the credential, the authentication context request message being in response to an initiation of a second process different than the first process; performing, by the authentication context registry server, a search for the authentication result data using the credential; and transmitting, by the authentication context registry server, the authentication result data or a derivative thereof to the data processor computer, wherein the data processor computer analyzes the authentication result data or the derivative thereof and decides to perform the second process based on the authentication result data or the derivative.

[0005] Another embodiment of the invention includes an authentication context registry server comprising: a processor; and a computer readable medium comprising instructions, executable by the processor, for performing operations comprising: receiving authentication result data associated with an authentication request initiated by an orchestrator computer and performed using a credential of a user, the authentication request being in response to the user initiating a first process; receiving, from a data processor computer, an authentication context request message associated with the credential, the authentication context request message being in response to an initiation of a second process different than the first process; performing a search for the authentication result data using the credential; and transmitting the authentication result data or a derivative thereof to the data processor computer, wherein the data processor computer analyzes the authentication result data or the derivative thereof and decides to perform the second process based on the authentication result data.

[0006] Another embodiment of the invention includes a method comprising: transmitting, by a data processing computer to an authentication context registry server, an authentication context request message comprising a credential, the authentication context request message associated with a second process, wherein the authentication context registry server is programmed to determine authentication result data using the credential, the authentication result data associated with authentication for a first process; receiving, by the data processing computer from the authentication context registry server, the authentication result data or a derivative thereof; evaluating, by the data processing computer, the authentication result data or a derivative thereof; and after evaluating the authentication result data or a derivative thereof, performing, by the data processing computer, the second process. [0007] Another embodiment of the invention includes a data processor computer comprising: a processor; and a computer readable medium comprising code executable by the processor, to perform a method comprising: transmitting, to an authentication context registry server, an authentication context request message comprising a credential, the authentication context request message associated with a second process, wherein the authentication context registry server is programmed to determine authentication result data using the credential, the authentication result data associated with authentication for a first process; receiving, from the authentication context registry server, the authentication result data or a derivative thereof; evaluating the authentication result data or a derivative thereof; and after evaluating the authentication result data or a derivative thereof, performing, by the data processing computer, the second process

[0008] These and other embodiments are described in further detail below.

TERMS

[0009] Before discussing specific embodiments of the invention, some descriptions of some terms may be helpful.

[0010] A “user” may include an individual. In some embodiments, a user may be associated with one or more personal accounts and/or user devices. The user may also be referred to as a cardholder, account holder, or consumer in some embodiments.

[0011] A “user device” may be a device that is operated by a user. Examples of user devices may include a mobile phone, a mobile communication device, a smartphone, a card, a payment card, a personal digital assistant (PDA), a laptop computer, a desktop computer, a server computer, a vehicle such as an automobile, a thin client device, a tablet PC, etc. Additionally, user devices may be any type of wearable technology device, such as a watch, earpiece, glasses, etc. The user device may include one or more processors capable of processing user input. The user device may also include one or more input sensors for receiving user input. As is known in the art, there are a variety of input sensors capable of detecting user input, such as accelerometers, cameras, microphones, etc. The user input obtained by the input sensors may be from a variety of data input types, including, but not limited to, audio data, visual data, or biometric data. The user device may comprise any electronic device that may be operated by a user, which may also provide remote communication capabilities to a network. Examples of remote communication capabilities include using a mobile phone (wireless) network, wireless data network (e.g., 3G, 4G, or similar networks), Wi-Fi, Wi-Max, or any other communication medium that may provide access to a network such as the Internet or a private network.

[0012] A “mobile communication device” may comprise any suitable electronic device that may be transported and operated by a user, which may also optionally provide remote communication capabilities to a network. Examples of remote communication capabilities include using a mobile phone (wireless) network, wireless data network (e.g., 3G, 4G, or similar networks), Wi-Fi, Bluetooth, Bluetooth Low Energy (BLE), Wi-Max, or any other communication medium that may provide access to a network such as the Internet or a private network. Examples of mobile communication devices include mobile phones (e.g., cellular phones), PDAs, tablet computers, net books, laptop computers, wearable devices (e.g., watches), vehicles such as automobiles and motorcycles, personal music players, hand-held specialized readers, etc. A mobile communication device may comprise any suitable hardware and software for performing such functions, and may also include multiple devices or components (e.g., when a device has remote access to a network by tethering to another device - i.e. , using the other device as a modem - both devices taken together may be considered a single mobile communication device).

[0013] A “resource” can be something of value to a user. A resource, for example, can include digital items and/or physical items. A resource can be an obtainable item. A resource can be owned by an entity. A resource can be a physical item such as goods. A resource can be a service that is provided by a merchant. A resource can be a digital item such as non-fungible tokens, secure data, etc. Another example of a resource is access to a secure or otherwise access-controlled location.

[0014] A “resource provider” may be an entity that can provide a resource such as goods, services, information, and/or access to a location (e.g., a parking space, a transit terminal, etc.). Examples of resource providers include merchants, governmental authorities, secure data providers, etc. A resource provider may operate one or more resource provider computers.

[0015] An “access device” may be any suitable device that provides access to a resource. An access device may be in any suitable form. Some examples of access devices include vending machines, kiosks, POS or point of sale devices (e.g., POS terminals), cellular phones, PDAs, personal computers (PCs), tablet PCs, hand-held specialized readers, set-top boxes, electronic cash registers (ECRs), automated teller machines (ATMs), virtual cash registers (VCRs), and the like. An access device may use any suitable contact or contactless mode of operation to send or receive data from, or associated with, a user mobile communication device. In some embodiments, an access device may include a reader, a processor, and a computer-readable medium. A reader may include any suitable contact or contactless mode of operation. For example, exemplary readers can include radio frequency (RF) antennas, optical scanners, bar code readers, or magnetic stripe readers to interact with a payment device and/or mobile communication device. The access device may include a user interface (e.g., hard/soft keyboard) that receives input (e.g., card credentials) from a user.

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

[0017] An “authorization entity” may be an entity that authorizes a request. Examples of an authorization entity may be an issuer, a governmental agency, a document repository, an access administrator, etc. An authorization entity may operate an authorization entity computer.

[0018] An “issuer” may refer to a business entity (e.g., a bank) that issues and optionally maintains an account for a user. An issuer may also issue payment credentials stored on a user device, such as a cellular telephone, smart card, tablet, or laptop to the consumer. [0019] A “processor” may refer to any suitable data computation device or devices. A processor may comprise one or more microprocessors working together to accomplish a desired function. The processor may include a CPU comprising at least one high-speed data processor adequate to execute program components for executing user and/or system -generated requests. The CPU may be a microprocessor such as AMD's Athlon, Duron and/or Opteron; IBM and/or Motorola's PowerPC; IBM's and Sony's Cell processor; Intel's Celeron, Itanium, Pentium, Xeon, and/or XScale; and/or the like processor(s).

[0020] A “memory” may be any suitable device or devices that can store electronic data. A suitable memory may comprise a non-transitory computer readable medium that stores instructions that can be executed by a processor to implement a desired method. Examples of memories may comprise one or more memory chips, disk drives, etc. Such memories may operate using any suitable electrical, optical, and/or magnetic mode of operation.

[0021] A “credential” may be any suitable information that serves as reliable evidence of worth, ownership, identity, or authority. A credential may be a string of numbers, letters, or any other suitable characters that may be present or contained in any object or document that can serve as confirmation. User credential examples can be a primary account number, driver's license ID, social security number, etc.

[0022] A "value credential" may be information associated with worth. Examples of value credentials include payment credentials, coupon identifiers, information needed to obtain a promotional offer, etc.

[0023] “Payment credentials” may include any suitable information associated with an account (e.g., a payment account and/or payment device associated with the account). Such information may be directly related to the account or may be derived from information related to the account. Examples of account information may include a PAN (primary account number or “account number”), username, expiration date, CVV (card verification value), dCVV (dynamic card verification value), CVV2 (card verification value 2), CVC3 card verification values, etc. CVV2 is generally understood to be a static verification value associated with a payment device. CVV2 values are generally visible to a user (e.g., a consumer), whereas CW and dCVV values are typically embedded in memory or authorization request messages and are not readily known to the user (although they are known to the issuer and payment processors). Payment credentials may be any information that identifies or is associated with a payment account. Payment credentials may be provided in order to make a payment from a payment account. Payment credentials can also include a username, an expiration date, a gift card number or code, and any other suitable information.

[0024] A “token” may be a substitute value for a credential. A token may be a string of numbers, letters, or any other suitable characters. A token may be bound to one or more devices (e.g., a user device). Examples of tokens include access tokens such as payment tokens, data that can be used to access secure systems or locations, etc.

[0025] A "payment token” may include an identifier for a payment account that is a substitute for an account identifier, such as a primary account number (PAN) and/or an expiration date. For example, a token may include a series of alphanumeric characters that may be used as a substitute for an original account identifier. For example, a token “4900 0000 0000 0001” may be used in place of a PAN “4147 0900 0000 1234.” In some embodiments, a token may be “format preserving” and may have a numeric format that conforms to the account identifiers used in existing transaction processing networks (e.g., ISO 8583 financial transaction message format). In some embodiments, a token may be used in place of a PAN to initiate, authorize, settle, or resolve a payment transaction or represent the original credential in other systems where the original credential would typically be provided. In some embodiments, a token value may be generated such that the recovery of the original PAN or other account identifier from the token value may not be computationally derived. Further, in some embodiments, the token format may be configured to allow the entity receiving the token to identify it as a token and recognize the entity that issued the token.

[0026] “Tokenization” is a process by which sensitive data is replaced with substitute data. For example, a real credential (e.g., a primary account number (PAN)) may be tokenized by replacing the real account identifier with a substitute number that may be associated with the real credential. Further, tokenization can be applied to any other information to substitute the underlying information with a token. “Token exchange” or “detokenization” can be a process of restoring the data that was substituted during tokenization. For example, a token exchange may include replacing a payment token with its associated primary account number (PAN). Further, detokenization or token exchange may be applied to any other information to retrieve the substituted information from a token. In some embodiments, token exchange can be achieved via a transactional message, such as an ISO message, an application programming interface (API), or another type of web interface (e.g., web request).

[0027] A “token service computer” can include a system that services tokens. In some embodiments, a token service computer can facilitate requesting, determining (e.g., generating) and/or issuing tokens, as well as maintaining an established mapping of tokens to primary account numbers (PANs) in a repository (e.g., token vault). In some embodiments, the token service computer may establish a token assurance level for a given token to indicate the confidence level of the token to PAN binding. The token service computer may include or be in communication with a token vault where the generated tokens are stored. The token service computer may support token processing of payment transactions submitted using tokens by de-tokenizing the token to obtain the actual PAN. An example of a token service compute is “Visa Token Service” (VTS).

[0028] A “token domain” may indicate an area and/or circumstance in which a token can be used. Examples of the token domain may include, but are not limited to, payment channels (e.g., e-commerce, physical point of sale, etc.), POS entry modes (e.g., contactless, magnetic stripe, etc.), and merchant identifiers to uniquely identify where the token can be used. A set of parameters (i.e. , token domain restriction controls) may be established as part of token issuance by the token service computer that may allow for enforcing appropriate usage of the token in payment transactions. For example, the token domain restriction controls may restrict the use of the token with particular presentment modes, such as contactless or e-commerce presentment modes. In some embodiments, the token domain restriction controls may restrict the use of the token at a particular merchant that can be uniquely identified. Some exemplary token domain restriction controls may require the verification of the presence of a token cryptogram that is unique to a given transaction. In some embodiments, a token domain can be associated with a token requestor.

[0029] A “token expiry date” may refer to the expiration date/time of the token. The token expiry date may be passed among the entities of the tokenization ecosystem during transaction processing to ensure interoperability. The token expiration date may be a numeric value (e.g., a 4-digit numeric value). In some embodiments, the token expiry date can be expressed as a time duration as measured from the time of issuance.

[0030] An “authentication request message” or “authentication request” may be a message that requests to confirm that something is true, genuine, or valid. In some embodiments, an authentication request message may request verification that a user is the true, genuine, or valid user. For example, the authentication request may include an electronic message that is sent to an authentication server computer and/or an authorizing entity computer to request authentication for a transaction.

[0031] An “authentication response message” or “authentication response” may be an electronic message reply to an authentication request message.

[0032] An "authentication context registry server" may store contextual information surrounding an authentication of a user. In some embodiments, the authentication context registry server may store context data relating to an authentication process such as when an authentication process was conducted, the resource provider or other entity associated with the authentication process, how the authentication process was performed, etc. In some embodiments, the authentication context registry server can store the authentication data (e.g., passwords, secrets, biometrics, etc.) that are verified during the authentication processes and the results of any authentication processes performed.

[0033] A "data processor computer" may include a computer that processes authentication result data or a derivative thereof. For example, a data processing computer may be a credential storage server, a token service computer, or any other entity that may transmit an authentication context request message to an authentication registry server to determine whether a user associated with a credential has been authenticated. [0034] An "orchestrator” can be an entity that arranges or directs actions to produce desired effects. An orchestrator can operate an orchestrator computer. An orchestrator computer can interact with various service computers (e.g., a credential storage computer, a token service computer, etc.) to obtain different services for a user. For example, an orchestrator can be a resource provider computer such as a merchant computer.

[0035] A “server computer” may include 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 functioning as a unit. In one example, the server computer may be a database server coupled to a Web server. The server computer may comprise one or more computational apparatuses and may use any of a variety of computing structures, arrangements, and compilations for servicing the requests from one or more client computers.

BRIEF DESCRIPTION OF THE DRAWINGS

[0036] FIG. 1 shows a block diagram of a system and a first overlaid process flow according to an embodiment.

[0037] FIG. 2 shows a block diagram of a system and a second overlaid process flow according to an embodiment.

[0038] FIG. 3 shows a block diagram of a system and a third overlaid process flow according to an embodiment.

[0039] FIG. 4 shows a block diagram of a resource provider computer according to an embodiment.

[0040] FIG. 5 shows a block diagram of a credential storage server according to an embodiment.

[0041] FIG. 6 shows a block diagram of an authentication context registry server according to an embodiment.

DETAILED DESCRIPTION

[0042] In embodiments of the invention, a method includes receiving authentication result data associated with an authentication request initiated by an orchestrator computer and performed using a credential of a user. The orchestrator computer can be a computer that orchestrates or coordinates a series of actions with different service providers for a user, preferably in a single online session. The authentication request can be in response to the user initiating a first process such as a process to store a credential with a credential storage computer such as a digital wallet. The method also includes receiving, from a data processor computer, an authentication context request message associated with the credential. The data processor can be different than the credential storage computer and can be a token service computer that performs tokenization of the credential. The authentication context request message can be in response to an initiation of a second process different than the first process. The first process could include storing a credential in a credential storage computer and tokenizing the credential. The method can also comprise performing a search for the authentication result data using the credential and transmitting the authentication result data or a derivative thereof to the data processor computer. The authentication result data could include data indicating whether or not the user was or was not authenticated for the first process or data relating to the circumstances regarding any past authentication processes (e.g., the raw data used to authenticate the user and/or any conditions or thresholds associated with an authentication decision). The data processor computer analyzes the authentication result data or the derivative thereof and decides to perform the second process based on the authentication result data.

[0043] Embodiments of the invention have a number of technical advantages. Embodiments of the invention can allow a data processor computer to use authentication result data relating to a prior authentication performed with respect to a user when the user is requesting a service provided by a different data processor computer providing a different type of service in a same online session. As a result, the user need not re-authenticate themselves when requesting different types of services performed by different data processing computers. Embodiments of the invention are also scalable because they do not require different data processor computers to have their own authentication services, or require different authentication services to know or coordinate with each other to provide convenience to the user.

[0044] FIG. 1 shows a block diagram of a system 100 and a first exemplary process that may be carried out using the system 100, according to an embodiment. [0045] System 100 includes a user 102, a resource provider computer 104, a credential storage server 106, an authentication context registry server 108, an authentication server computer 110, an authorizing entity computer 112, a user device 114, and a token service computer 116.

[0046] The resource provider computer 104 can be in operative communication with the authentication server computer 110, the credential storage server 106, the token service computer 116, the user device 114, and the user 102.

[0047] The authentication context registry server 108 can be in communication with the authentication server computer 110, the credential storage server 106, and the token service computer 116. The authorizing entity computer 112 can be in communication with the user device 114, the authentication server computer 110, and the token service computer 116.

[0048] Each of the devices and computers may be in operative communication with each other. For simplicity of illustration, a certain number of components are shown in system 100. It is understood, however, that embodiments of the invention may include more or less components than are illustrated in system 100.

[0049] The devices and computers in the system 100 can communicate with one another using a communication network or line (not pictured). The communication network or line can take any suitable form, and may include any one and/or the combination of the following: a direct connection or interconnection; the Internet; a Local Area Network (LAN); a Metropolitan Area Network (MAN); an operating Missions as Nodes on the Internet (OMNI); a cellular network, a secured custom connection; a Wide Area Network (WAN); a wireless network (e.g., employing protocols such as, but not limited to a Wireless Application Protocol (WAP), l-mode, and/or the like); and/or the like. Messages between the computers and devices in system 100 may be transmitted using a communication protocol such as, but not limited to, File Transfer Protocol (FTP); Hypertext Transfer Protocol (HTTP); Secure Hypertext Transfer Protocol (HTTPS); Secure Socket Layer (SSL), ISO (e.g., ISO 8583) and/or the like.

[0050] The user device 114 may be associated with the user 102. The resource provider computer 104 may be associated with a resource provider such as a merchant, an entity that provides access to a secure location, or an entity that provides access to secure data. The user 102 can interact with the resource provider computer 104 using the user device 114. As an example, the user 102 may be interfacing with an e-commerce site (e.g., via the user device 114 or another device) executing on the resource provider computer 104 and may have initiated a checkout process to obtain resources from the resource provider computer.

[0051] The user 102 may interact with a user interface associated with the resource provider computer 104 and/or the user device 114. The user interface may be used to receive input from the user 102. The input may indicate one or more credentials (e.g., a PAN) of the user 102 and authentication data of the user 102 (e.g., a password, a fingerprint, etc.). The user device 114 may transmit the user input to the resource provider computer 104.

[0052] The input received by the resource provider computer 104, from the user 102, may include credentials, instructions to proceed with a checkout process, instructions to add a card to a wallet, or any other information or instructions from the user 102. In some embodiments, the input provided by the user 102 may initiate different processes that are carried out using one or more services. The processes may be part of a single online session between the user 102 and the resource provider computer 104. The processes can include, for example: adding a credential to a credential storage computer, tokenizing a credential, performing a transaction such as a payment transaction, etc.

[0053] The resource provider computer 104 may be operated by a resource provider. The resource provider computer 104 may be configured to receive and/or transmit information to at least the credential storage server 106, the authentication server computer 110, and the token service computer 116. In some instances, the resource provider computer 104 may be characterized as an “orchestrator computer” since it can orchestrate or coordinate the initiation of different processes on behalf of the user 102.

[0054] The credential storage server 106 may store credentials such as PANs or tokens. The credential storage server 106 may be a digital wallet server computer in some embodiments. [0055] The authentication server computer 110 can be programmed to perform authentication processes including message routing and authentication decision processes. In some embodiments, it is a directory server that maintains a directory of authorizing entity computer addresses as they relate to credentials or portions of credentials (e.g., BINs or bank identification numbers). In some embodiments, the authentication process can include an authentication request message that includes a challenge that is transmitted to the user device 114. The challenge may be a request for a secret such as a password or personal identification number (PIN). In some embodiments, the authentication server computer 110 can communicate with the authorizing entity computer 112 to initiate a challenge to the user 102 or the user device 114.

[0056] The authorizing entity computer 112 may be operated by an authorizing entity such as an issuer. The authorizing entity computer 112 can manage an account associated with the user 102. The account may be associated with a credential. The authorizing entity computer 112 can also authorize or not authorize transactions using the account, the credential, or a token associated with the credential.

[0057] The authentication context registry server 108 can be a central authentication repository of authentication result data from prior authentication processes for different users seeking services from different service providers. The authentication context registry server 108 can store data relating to authentication results, data relating to the authentication processes that produced the authentication results, and optionally the raw data that was used in the authentication processes.

[0058] The token service computer 116 can perform tokenization services. Tokenization services can include issuing and provisioning tokens, exchanging tokens for credentials during transactions, token to device binding, etc.

[0059] Methods according to embodiments can be described with reference to FIG. 1 . In the methods described with respect to FIG. 1 , the credential storage server 106 and the resource provider computer 104 may perform the functionality of an orchestrator. In these embodiments, the credential storage server 106 can be a digital wallet server and the resource provider computer 104 can be a merchant computer such as a merchant server operating a Website.

[0060] At step S102, the resource provider computer 104 can receive a credential (e.g., an account number such as a PAN) of the user 102 from the user device 114. In certain embodiments, the user device 114 transmits the credential to the resource provider computer 104 during a transaction to purchase goods or services from the resource provider operating the resource provider computer 104. During the transaction, the user 102 can be prompted to decide if the user 102 wants to add the credential to the credential storage server 106. The user 102 may wish to do this so that future transactions conducted with the resource provider computer 104 do not require the user to provide the credential, thereby saving the user time in further transactions. In this example, the user 102 wishes to save the credential to the credential storage server 106. The saving of the credential to the credential storage server can be a first process.

[0061] At step S104, the resource provider computer 104 transmits the credential to the credential storage server 106 as part of the first process. The credential storage server 106 may need to authenticate the user 102 before storing the credential. Before doing so, however, the credential storage server 106 can determine if the user 102 has been previously authenticated in a different process and if so, then also determine if the prior authentication can be used to authenticate the user in order to perform the process of storing the credential.

[0062] At step S106, the credential storage server 106 may transmit an authentication context request message to the authentication context registry server 108. The authentication context request message may include the credential. The authentication context request message may cause the authentication context registry server 108 to search for the authentication result data for prior authentications.

[0063] At step S108, the authentication context registry server 108 determines that it does not have authentication result data associated with the credential.

Because there is no prior authentication result data associated with the credential, the credential storage server 106 can then initiate an authentication process before performing the first process. [0064] At step S110, the credential storage server 106 transmits an authentication request message to the authentication server computer 110. The authentication request message may include the credential. The authentication server computer 110 may use the credential to determine the authorization entity computer 112 which can authenticate the user 102. In this regard, the authentication server computer 110 may map the credentials of users, or portions thereof, to network addresses of authorizing entity computers.

[0065] At step S112, the authentication server computer 110 may route the authentication request to the authorization entity computer 112. The authorization entity computer 112 may receive the authentication request message including the credential. Using the credential, the authorizing entity computer 112 can determine the address of the user device 114 (e.g., a network address or phone number). The user 102 may have previously provided the address of the user device 114 to the authorizing entity computer 112 as part of an enrollment process.

[0066] At step S114, the authorizing entity computer 112 then transmits a challenge message to the user device 114. The challenge message may request a secret such as a PIN or password from the user 102, or may obtain device data associated with the user device 114 to authenticate the user 102 or the user device 114. In other embodiments, the challenge message may be a one-time passcode that is provided to the user device 114 and is provided by the user 102 to the authorizing entity computer 112.

[0067] At step S116, the user device 114 may prompt the user 102 for a response based on the received challenge message. The prompt may request the user 102 to enter authentication data such as a secret, biometric data, etc.

[0068] At step S118, the user 102 may enter the authentication data into the user device 114 (e.g., via a user interface).

[0069] At step S120, the user device 114 may transmit a challenge response comprising the authentication data to the authorizing entity computer 112. The authorizing entity computer 112 can then determine if the authentication data in the challenge response is the expected authentication data (e.g., a received password matches an enrolled password stored at the authorizing entity computer 112). After the authorizing entity computer 112 performs the authentication process, it can generate authentication result data. The authentication result data can include the result of the authentication process (e.g., the user 102 is either authenticated or not authenticated), and optionally the context of the authentication process (e.g., the user 102 was authenticated by the authorizing entity computer 112 using a password entered into a previously registered user device 114, the date and time of the authentication, etc.).

[0070] At step S122, an authentication response message may be transmitted by the authorizing entity computer 112 to the authentication server computer 110. The authentication response message may include the authentication result data.

[0071] At step S124, the authentication response message is transmitted from the authentication server computer 110 to the credential storage server 106.

Assuming that the authentication response message indicates a positive authentication, the credential storage server 106 can then store the credential of the user 102 pursuant to the first process.

[0072] At step S126, after the credential storage server 106 stores the credential, it may transmit the authentication result data to the authentication context registry server 108. The credential storage server 106 may alter, add, and/or remove data from the authentication result data before transmitting the authentication result data to the authentication context registry server 108. For example, the credential storage server 106 may add data such as an identifier for the resource provider computer 104 that initiated the first process.

[0073] The authentication context registry server 108 may store the authentication result data. As noted above, the authentication result data can include data regarding the authentication decision (authenticated or not) as well as the context data relating to the authentication.

[0074] In certain embodiments, after step S126, the authentication context registry server 108 transmits an acknowledgment response to the credential storage server 106 indicating that the authentication result data was stored or not stored by the authentication context registry server 108.

[0075] At step S128, after storing the credential, the credential storage server 106 may transmit a credential addition status response to the resource provider computer 104. The credential addition status response may include status information that indicates whether the credential was successfully stored.

[0076] During the same online session with the resource provider computer 104, the user 102 causes a second process, such as tokenization of the credential, to be performed. The second process is different than the first process, but can be conducted during the same online session between the user 102 and the resource provider operating the resource provider computer 104. In this example, in the second process, the user 102 may be prompted to decide whether they wish to tokenize the credential after the credential was stored by the credential storage server 106. In the flow in FIG. 1 , the user 102 agrees to tokenize the credential.

[0077] At step S130, the resource provider computer 104 then transmits a token request message comprising the credential to the token service computer 116. Before deciding whether to perform the second process of tokenizing the credential, the token service computer 116 can determine if the authentication context registry server 108 has prior authentication result data that it can use to authenticate the user, instead of independently and separately initiating re-authentication of the user.

[0078] At step S132, the token service computer 116 may transmit an authentication context request message comprising the credential to the authentication context registry server 108. The authentication context request message may then be received by the authentication context registry server 108 from the token service computer 116. The authentication context registry server 108 may perform a search for the authentication result data using the credential. This time, the authentication context registry server 108 has authentication result data from the authentication performed in association with the first process of adding the credential to the credential storage computer. The authentication result data can include the prior positive authentication result, as well as the context data associated with the prior authentication result.

[0079] In some embodiments, the authentication result data can be transmitted by the authentication context registry server 108 to the token service computer 116. The token service computer 116 can then decide if the authentication result data is sufficient for it to perform the second process of tokenizing the credential without separately and independently re-authenticating the user 102. The token service computer 116 can have conditions or rules that allow it to make that decision. For example, the token service computer 116 may have a rule that a satisfactory authentication process can only include a one-time password or biometric authentication process. A static password authentication process may not be sufficient for the token service computer 116 to perform the second process. In this case, the token service computer 116 can then separately and independently re- authenticate the user 102.

[0080] In other embodiments, the authentication context registry server 108 can transmit a derivative of the authentication result data to the token service computer 116. The derivative of the authentication result data may be data that is derived from the authentication result data. For example, the token service computer 116 can have conditions or rules for authentication that must be satisfied before it can perform the second process. Those conditions or rules may be stored at the authentication context registry server 108 and may be applied to the authentication result data stored in the authentication context registry server 108. For example, if the authentication context registry server 108 stores a rule that a satisfactory authentication process for the token service computer 116 can only include a onetime password or biometric authentication process, and the authentication result data indicates that the prior authentication process used a static password, then the authentication context registry server 108 can conclude that the user 102 is “not authenticated” for the second process. The “not authenticated” indication can be a derivative of the authentication result data and can be provided to the token service computer 116.

[0081] At step S134, the authentication context registry server 108 may transmit the authentication result data or the derivative thereof to the token service computer 116.

[0082] The token service computer 116 may analyze the authentication result data or the derivative thereof and decide whether to continue to perform the second process.

[0083] At step S136, assuming that the prior authentication result data is sufficient to satisfy the token service computer 116, it may then generate or obtain a token using the credential. [0084] At step S138, a notification may be transmitted from the token service computer 116 to the authorizing entity computer 112. The notification may notify the authorizing entity computer 112 that the token has been generated and has been linked or bound to the credential and optionally the user device 114 of the user 102. The notification may also include at least a portion of the authentication result data if it was received by the token service computer 116. The token service computer 116 may store the authentication result data or the derivative thereof in memory and associate the notification data to the credential.

[0085] At step S140, the token service computer 116 may transmit the token to the resource provider computer 104. The token may be stored and/or used by the resource provider computer 104 to conduct one or more future transactions (e.g., payment transactions) related to the credential. In certain embodiments, the token is transmitted from the resource provider computer 104 to the user device 114, and the user device 114 can use the token to conduct future transactions.

[0086] FIG. 2 shows a block diagram of a system 100 and second exemplary overlaid process flow.

[0087] The system 100 in FIG. 2 may include similar components as the components in FIG. 1 , and like numerals designating like elements. In this example, the credential storage server 106 may be an orchestrator computer.

[0088] Steps S202-226 in FIG. 2 may be similar to steps S102-126 in FIG. 1 , so the descriptions thereof are incorporated herein and are not repeated.

[0089] At step S228, the credential storage server 106 may initiate a second process. The second process may be different than the first process. The second process may include tokenizing the credential. The second process and the first process may be part of the same online session. The credential storage server 106 may transmit a token request message comprising the credential to the token service computer 116.

[0090] Steps S230-236 may be performed in a similar manner as the steps S132-138 in FIG. 1 , so the descriptions thereof are incorporated herein and are not repeated. [0091] At step S238, the token service computer 116 may transmit the token to the credential storage server 106. The token may be stored and/or used by the credential storage server 106. The credential storage server 106 may transmit information to the resource provider computer 104 to inform the resource provider computer 104 that the token has been received and/or generated for the credential.

[0092] Step S240 may be performed in a similar manner as step S128 in FIG. 1 , so the descriptions thereof are incorporated herein and are not repeated.

[0093] FIG. 3 shows a block diagram of a system 100 and a third overlaid process flow according to an embodiment.

[0094] The system 300 in FIG. 3 may include similar components as the components in FIG. 1 , and like numerals designating like elements. In this example, the resource provider computer 104 may be an orchestrator computer.

[0095] Step S302 may be performed in a similar manner as the step S102 in FIG. 1 ,the description is incorporated herein and is not repeated.

[0096] At step S304, an authentication request message is transmitted from the resource provider computer 104 to the authentication server computer 110. The authentication request message may include the credential. The authentication server computer 110 may process the authentication request to determine which authorization entity computer 112 to transmit the authorization request to.

[0097] Steps S306-316 may be performed in a similar manner as the steps S112-122 in FIG. 1 , so the descriptions thereof are incorporated herein and are not repeated.

[0098] At step S318, the authentication server computer 110 may transmit the authentication result data to the authentication context registry server 108 (instead of the credential storage server 106 as illustrated in FIG. 1 ).

[0099] At step S320, an authentication response message is transmitted from the authentication server computer 110 to the resource provider computer 104. The authentication response message may include the authentication result data. The authentication result data may be the same authentication result data result data that the authentication server computer 110 received from the authorizing entity computer 112.

[0100] In step S322, after receiving the authentication response message indicating a positive authentication from the authentication server computer 110, the resource provider computer 104 can transmit an instruction to add the credential to the credential storage server 106, and the credential storage server 106 can store the credential.

[0101] Steps S322-326 may be performed in a similar manner as the steps S104-108 described with respect to FIG. 1 , and the descriptions thereof are incorporated herein.

[0102] Steps S328-340 may be performed in a similar manner as the steps S128-140 in FIG. 1 , the descriptions thereof are incorporated herein and are not repeated.

[0103] FIG. 4 shows a block diagram of a resource provider computer 104, according to an embodiment.

[0104] The resource provider computer 104 may include a processor 402. The resource provider computer 104 can include a network interface 404, a database 412, and a computer readable medium 418 coupled to the processor 402.

[0105] The network interface 404 may be any suitable network interface operable to interface with other external devices. The network interface 404 may enable the resource provider computer 104 to transmit and receive information over a network (e.g., local area network (LAN), wide area network (WAN)).

[0106] The database 412 may include a hierarchical database, a network database, an object-oriented database, a relational database, and/or a cloud database, etc. The database may be stored in memory. The database 412 memory may be any magnetic, electronic, or optical memory. It can be appreciated that the memory may include any number of memory modules. An example of memory may be dynamic random access memory (DRAM).

[0107] The database 412 may be used to store information such as time/date data 414, authentication data 416, credentials 432, and/or transaction data 434. The time/date data 414 may include dates and times of transactions. The transaction data 434 can include dates related to transactions conducted by the resource provider computer 104.

[0108] The computer readable medium 418 may be any magnetic, electronic, optical, or other computer-readable medium. The computer readable medium 418 may comprise any combination of volatile and/or non-volatile memory such as, for example, buffer memory, RAM, DRAM, ROM, flash, or any other suitable memory device, alone or in combination with other data storage devices. Computer readable medium 418 may include one or more software modules, such as a transaction processing module 420, a token acquisition module 422, an authentication verification module 424, and an encryption module 426.

[0109] The transaction processing module 420 and the processor 402 may be used to allow the resource provider computer 104 to process transaction messages such as authorization request and response messages, authentication request and response messages, etc.

[0110] The token acquisition module 422 and the processor 402 may be used by the resource provider computer 104 to transmit token request messages and receive token response messages.

[0111] The authentication verification module 424 and the processor 402 may perform authentication processing as described herein.

[0112] The encryption module 426 may be used to encrypt and/or decrypt information. Information may be encrypted before being transmitted and/or stored.

[0113] FIG. 5 shows a block diagram of a credential storage server 106, according to an embodiment.

[0114] The credential storage server 106 may include a processor 502. The credential storage server 106 may include a network interface 504, a database 506, and a computer readable medium 516 coupled to the processor 502.

[0115] The network interface may perform functions similar to those described with respect to the network interface 504 included in resource provider computer 104. [0116] The database 506 may be used to store information such as authentication context data 508, authentication result data 510, tokens 512, credentials 514, etc.

[0117] The computer readable medium 516 may include one or more software modules, such as an authentication context acquisition module 518, a token acquisition module 422, an authentication verification module 424, a derivative result generation module 520, and an encryption module 426.

[0118] The authentication context acquisition module 518 and the processor 502 may cause the credential storage server 106 to generate and transmit (e.g., to an authentication context registry server) an authentication context request message.

[0119] The token acquisition module 422 may perform functions similar to those described with respect to the token acquisition module 422 included in resource provider computer 104.

[0120] The authentication verification module 424 may perform functions similar to those described with respect to the token acquisition module 422 included in resource provider computer 104.

[0121] The encryption module 426 may perform functions similar to those described with respect to the token acquisition module 422 included in resource provider computer 104.

[0122] FIG. 6 shows a block diagram of an authentication context registry server 108, according to an embodiment. The authentication context registry server 108 can comprise context data relating to the authentication result data, the context data is associated with a plurality of different types of authentication processes and details regarding the plurality of different types of authentication processes. For example, details regarding biometric authentication processes can be different than details regarding one-time password authentication processes. Further, some forms of authentication may be stronger than others, and the authentication context registry server 108 can include data regarding the strength of such different authentication processes as they would be used to authenticate a user prior to performing different processes. [0123] The authentication context registry server 108 may include a processor 602. The authentication context registry server 108 may include a network interface 604, a database 606, and a computer readable medium 622 coupled to the processor 602.

[0124] The processor 602 may be any suitable processor operable to carry out instructions on the authentication context registry server 108. The processor 602 may be coupled to other units of the authentication context registry server 108 including the network interface 604, the database 606, and the computer readable medium 622.

[0125] The network interface 604 may perform functions similar to those described with respect to the network interface 404 included in resource provider computer 104.

[0126] The database 606 may be used to store information such as authentication result data 610, authentication context data 612, credentials 614, and rules or conditions for generating derivatives of authentication result data 610.

[0127] The computer readable medium 622 may include one or more modules, such as a storage module 624, a search module 626, and a derivative result generation module 628.

[0128] The storage module 624 and the processor 602 can store authentication result data 610 or any of the other data in the database 606.

[0129] The search module 626 and the processor 602 may be used to perform searches of the data in the database 606.

[0130] The derivative result generation module 628 and the processor 602 may be configured to receive authentication result data 510 (e.g., from the authentication context acquisition module 518) and generate a derivative thereof as described above.

[0131] Any of the software components or functions described in this application may be implemented as software code to be executed by a processor using any suitable computer language such as, for example, Java, C, C++, C#, Objective-C, Swift, or scripting language such as Perl or Python using, for example, conventional or object-oriented techniques. The software code may be stored as a series of instructions or commands on a computer readable medium for storage and/or transmission, suitable media include random access memory (RAM), a read only memory (ROM), a magnetic medium such as a hard-drive or a floppy disk, or an optical medium such as a compact disk (CD) or DVD (digital versatile disk), flash memory, and the like. The computer readable medium may be any combination of such storage or transmission devices.

[0132] Such programs may also be encoded and transmitted using carrier signals adapted for transmission via wired, optical, and/or wireless networks conforming to a variety of protocols, including the Internet. As such, a computer readable medium according to an embodiment of the present invention may be created using a data signal encoded with such programs. Computer readable media encoded with the program code may be packaged with a compatible device or provided separately from other devices (e.g., via Internet download). Any such computer readable medium may reside on or within a single computer product (e.g., a hard drive, a CD, or an entire computer system), and may be present on or within different computer products within a system or network. A computer system may include a monitor, printer, or other suitable display for providing any of the results mentioned herein to a user.

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

[0134] One or more features from any embodiment may be combined with one or more features of any other embodiment without departing from the scope of the invention.

[0135] As used herein, the use of "a," "an," or "the" is intended to mean "at least one," unless specifically indicated to the contrary.

Claims

WHAT IS CLAIMED IS:

1 . A method comprising: receiving, by an authentication context registry server, authentication result data associated with an authentication request initiated by an orchestrator computer and performed using a credential of a user, the authentication request being in response to the user initiating a first process; receiving, by the authentication context registry server from a data processor computer, an authentication context request message associated with the credential, the authentication context request message being in response to an initiation of a second process different than the first process; performing, by the authentication context registry server, a search for the authentication result data using the credential; and transmitting, by the authentication context registry server, the authentication result data or a derivative thereof to the data processor computer, wherein the data processor computer analyzes the authentication result data or the derivative thereof and decides to perform the second process based on the authentication result data or the derivative thereof.

2. The method of claim 1 , wherein the first process and the second process are part of a same online session.

3. The method of claim 1 , wherein the data processor computer is a credential storage server or a token service computer.

4. The method of claim 1 , wherein the first process comprises adding the credential to a credential storage server and the second process comprises tokenizing the credential.

5. The method of claim 1 , wherein the authentication context registry server comprises context data relating to the authentication result data, the context data is associated with a plurality of different types of authentication processes and details regarding the plurality of different types of authentication processes.

6. The method of claim 1 , wherein transmitting, by the authentication context registry server, the authentication result data or the derivative thereof to the data processor computer comprises transmitting the derivative of the authentication result data.

7. The method of claim 1 , wherein the credential is an account identifier.

8. The method of claim 1 , wherein the authentication result data relates to a result of a biometric, one-time password, or static secret authentication process.

9. An authentication context registry server comprising: a processor; and a computer readable medium comprising instructions, executable by the processor, for performing operations comprising: receiving authentication result data associated with an authentication request initiated by an orchestrator computer and performed using a credential of a user, the authentication request being in response to the user initiating a first process; receiving, from a data processor computer, an authentication context request message associated with the credential, the authentication context request message being in response to an initiation of a second process different than the first process; performing a search for the authentication result data using the credential; and transmitting the authentication result data or a derivative thereof to the data processor computer, wherein the data processor computer analyzes the authentication result data or the derivative thereof and decides to perform the second process based on the authentication result data or the derivative thereof.

10. The authentication context registry server of claim 9, wherein the first process and the second process are part of a same online session.

11 . The authentication context registry server of claim 9, wherein the data processor computer is a credential storage server or a token service computer.

12. The authentication context registry server of claim 9, wherein the first process comprises adding the credential to a credential storage computer and the second process comprises tokenizing the credential.

13. The authentication context registry server of claim 9, wherein the authentication context registry server comprises context data relating to the authentication result data, the context data is associated with a plurality of different types of authentication processes and details regarding the plurality of different types of authentication processes.

14. The authentication context registry server of claim 9, wherein transmitting, by the authentication context registry server, the authentication result data or the derivative thereof to the data processor computer comprises transmitting the derivative of the authentication result data.

15. The authentication context registry server of claim 9, wherein the authentication result data comprises an authentication result and context data associated with the authentication result.

16. The authentication context registry server of claim 9, wherein the authentication result data comprises an authentication result and context data associated with the authentication result, wherein the context data relates to a time and manner in which the authentication result was determined.

17. A method comprising: transmitting, by a data processing computer to an authentication context registry server, an authentication context request message comprising a credential, the authentication context request message associated with a second process, wherein the authentication context registry server is programmed to determine authentication result data using the credential, the authentication result data associated with authentication for a first process; receiving, by the data processing computer from the authentication context registry server, the authentication result data or a derivative thereof; and evaluating, by the data processing computer, the authentication result data or the derivative thereof; and after evaluating the authentication result data or the derivative thereof, performing, by the data processing computer, the second process.

18. The method of claim 17, wherein the first process and the second process are part of a same online session.

19. The method of claim 17, wherein the first process comprises adding the credential to a credential storage computer and the second process comprises tokenizing the credential.

20. The method of claim 17, wherein the data processing computer is a token service computer.