Secure token distribution

Abstract

A method for facilitating certificate signing requests with a registration authority is disclosed. In at least one embodiment, a registration authority computer can receive a certificate signing request associated with a token requester. The registration authority can authenticate the identity of the token requester and forward the certificate signing request to a certificate authority computer. A token requester ID and a signing certificate can be provided by the certificate authority computer and forwarded to the token requester. The token requester can utilize the token requester ID to generate a digital signature for subsequent token-based transactions.

Description

[0001] This application is a continuation-in-part of International Application No. PCT / US2016 / 065005, International Filing Date, which entered the National Stage in the United States on December 5, 2016, under International Application No. 201680068352.8, entitled "Secure Token Distribution," filed December 5, 2016, the entire contents of which are hereby incorporated by reference in its entirety for all purposes.

[0002] Cross Reference to Related Applications

[0003] This application is a non-provisional of, and claims the benefit of the filing date of, U.S. Provisional Application No. 62 / 263,503, filed December 4, 2015, the entire contents of which are hereby incorporated by reference for all purposes. BACKGROUND

[0004] Tokens provide the ability to introduce new domain controls to further enhance security within the ecosystem. Some token types are categorized by how they are stored when at rest (HCE (Host Card Emulation), SE (Secure Element), or COF (Card On File)). A TAVV (Transaction Authentication Verification Value) is generated for each transaction. The TAVV ensures that the request originated from the original token requestor (pre-authenticated entity) and that the transaction is unique. Generating a TAVV outside of a secure execution environment can be difficult. In some cases, the token provider offers a service to the token requestor to obtain a TAVV prior to submitting a token transaction. However, this creates several problems for the token requestor.

[0005] Requiring the token requestor to obtain a TAVV will present several challenges. First, the TAVV adds additional time to contact the token service and wait for a response to the TAVV submission. Second, additional symmetric key development and storage is required for authentication to the token provider. Third, the token provider can have to establish new distribution strategies to establish a direct token requestor relationship. In addition, other token providers in the ecosystem will offer a variety of solutions that can vary greatly.

[0006] Embodiments of the present invention address these and other issues. SUMMARY

[0007] Embodiments of the invention relate to token management. In particular, embodiments of the invention relate to providing improved mechanisms for a token requestor (e.g., a merchant or other token requestor, such as a wallet application) to obtain a token from a token provider. In some embodiments, the key generation work can be offloaded to the token requestor rather than requiring the token provider to generate a TAVV. Further, the authentication of the token requestor can be performed by an entity other than the token provider (e.g., an acquirer). With such techniques, the computational burden on the token provider can be reduced by freeing the token provider from generating or obtaining a TAVV.

[0008] One embodiment of the invention relates to a method comprising receiving, at a registration authority computer, a certificate signing request from a token requestor computer. The method can also include authenticating, by the registration authority computer, a token requestor associated with the token requestor computer. The method can also include transmitting the certificate signing request to a certificate authority computer. The method can also include receiving, from the certificate authority computer, a token requestor identifier (ID) assigned to the token requestor and a signed certificate. The method can also include transmitting the signed certificate and the token requestor ID to the token requestor computer. In at least one embodiment, the receipt of the token requestor ID by the token requestor computer can enable the token requestor computer to generate a digital signature for a subsequent token-based transaction.

[0009] Another embodiment of the invention relates to a registration authority computer comprising a processor and a computer readable medium coupled to the processor, the computer readable medium comprising code executable by the processor for implementing a method. The method can receive a certificate signing request from a token requestor computer. The method can also include authenticating, based at least in part on the certificate signing request, a token requestor associated with the token requestor computer. The method can also include transmitting the certificate signing request to a certificate authority computer. The method can also include receiving, from the certificate authority computer, a signed certificate and a token requestor identifier (ID) assigned to the token requestor. The method can also include transmitting the signed certificate and the token requestor ID to the token requestor computer. In at least one embodiment, the receipt of the token requestor ID by the token requestor computer can enable the token requestor computer to generate a digital signature for a subsequent token-based transaction.

[0010] Another embodiment of the invention relates to a method comprising receiving a first payment token associated with a first token domain. The method can further comprise transmitting a token provisioning request message to a token provider computer using the first payment token, wherein the token provider computer generates a second payment token in response to receiving the token provisioning request message, the second payment token being associated with a second token domain different from the first token domain. The method can further comprise receiving the second payment token from the token provider computer.

[0011] These and other embodiments of the invention will be described in further detail below. BRIEF DESCRIPTION OF DRAWINGS

[0012] Figure 1 A diagram illustrating the distribution of secure credentials is shown.

[0013] Figure 2 A diagram of a signed hash composed of data elements is shown.

[0014] Figure 3 A flowchart illustrating a token provisioning process for a PAN is shown.

[0015] Figure 4 A flowchart illustrating token provisioning for another token is shown.

[0016] Figure 5 A flowchart regarding a token processing flow is shown.

[0017] Figure 6 A diagram illustrating token reuse within a token domain is shown.

[0018] Figure 7 A diagram illustrating an environment in which a token is reused within a token domain is shown.

[0019] Figure 8 A diagram illustrating an environment in which a resource provider uses a unique token is shown.

[0020] Figure 9 Another diagram illustrating reuse of a token requester ID is shown.

[0021] Figure 10 A diagram illustrating a registration matching process is shown. DETAILED DESCRIPTION

[0022] In the following description, various embodiments will be described. For the purpose of explanation, specific configurations and details are set forth in order to provide a thorough understanding of the embodiments. However, it will also be apparent to one skilled in the art that the embodiments can be practiced without the specific detail. Furthermore, well-known features can be omitted or simplified in order not to obscure the embodiment being described.

[0023] Before discussing details of some embodiments of the application, a description of some terms can be helpful in understanding the various embodiments.

[0024] A "payment token" or "token" can include an identifier of a payment account that is a substitute for an account identifier such as a primary account number (PAN). For example, a token can include a string of alphanumeric characters that can be used as a substitute for the original account identifier. For example, the token "4900 0000 0000 0001" can be used in place of the PAN "4147 0900 0000 1234." In some embodiments, a 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 token can be used in place of a PAN to initiate, authorize, process, or settle a payment transaction, or to represent an original credential in other systems that would normally provide the original credential. In some embodiments, a token value can be generated such that the recovery of a PAN or other account identifier from the token value cannot be achieved by computational means. Additionally, in some embodiments, the token format can be configured to cause an entity receiving the token to identify it as a token and to identify the entity that issued the token.

[0025] A "token service" can include a system that provides token (e.g., payment token) services. In some embodiments, a token service can facilitate requesting, determining (e.g., generating), and / or issuing tokens, as well as maintaining a mapping of established tokens to token requestor IDs (TRIDs) in a repository (e.g., a token repository). In some embodiments, a token service can establish a token assurance level for a given token to indicate a level of confidence in the token-to-PAN binding. A token service can include or be in communication with a token repository that stores generated tokens. A token service can support token processing of payment transactions submitted using tokens by enabling token detokenization to obtain the actual PAN. In some embodiments, a token service can include only a token provider computer, or a combination of a token provider computer and other computers (e.g., 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 provider by implementing a token service in accordance with embodiments of the application.

[0026] A "token domain" can indicate an area and / or environment in which a token can be used. Examples of token domains can include, but are not limited to, a payment channel (e.g., e-commerce, physical point-of-sale, etc.), a POS input mode (e.g., contactless, magnetic stripe, etc.), and a merchant identifier to uniquely identify where the token can be used. A set of parameters (i.e., token domain restriction controls) can be established by a token service provider as part of token issuance that can allow for the enforcement of proper use of a token in a payment transaction. For example, a token domain restriction control can limit use of a token in a particular presentation mode, such as a contactless or e-commerce presentation mode. In some embodiments, a token domain restriction control can limit use of a token at a particular merchant that can be uniquely identified. Some example token domain restriction controls can require the presence of a token password that is unique to a given transaction. In some embodiments, a token domain can be associated with a token requestor.

[0027] A "certificate signing request" is a block of text provided to a certificate authority when requesting a certificate signature. A certificate signing request can include identifying information for a requestor. For example, a certificate signing request can include, but is not limited to, a legally registered name of a requestor (or an organization of a requestor), a domain name associated with the requestor, an organizational unit of the requestor (e.g., a department of a requestor organization), a city / region of the requestor, a state / country / district of the requestor, a country of the requestor, and an email address associated with the requestor and / or a public key of an asymmetric key pair associated with the requestor. A certificate authority (or other authentication system) can authenticate a requestor using the identifying information contained in a certificate signing request. In addition, a certificate authority can use the identifying information to create / manage a certificate or mapping that enables the certificate authority to ascertain the identity of a sender in future transactions.

[0028] A "digital signature" is a type of electronic signature that employs a digital code that is particularly difficult to replicate. A digital signature can be used to verify the reliability and integrity of an electronic message. A digital signature is intended to address the problems of tampering and forgery in digital communications. A digital signature can provide additional assurance of the source, identity, status of an electronic transaction and serves as a confirmation of the signer's informed consent.

[0029] An "asymmetric key" is also known as a public / private key pair, which is used for asymmetric encryption. In a public key encryption system, a device can encrypt a message using the recipient's public key, but such a message can only be decrypted using the recipient's private key. Public key cryptography systems often rely on cryptographic algorithms that are based on mathematical problems for which no efficient solution is currently known. Message authentication involves hashing a message to generate a "digest" and encrypting the digest using a private key to generate a digital signature. Another device can then verify the signature by 1) computing a hash of the message, 2) decrypting the signature using the signer's public key, and 3) comparing the computed digest to the decrypted digest.

[0030] A "digital wallet" refers to an electronic module that allows a device to conduct electronic commerce transactions. In some embodiments, a digital wallet can store account information (e.g., bank account number, PAN, etc.) associated with a user. A digital wallet can store or be associated with one or more unique asymmetric key pairs or TAVVs, etc. In at least one embodiment, a digital wallet can store or otherwise have access to a token. Such a digital wallet can be configured to encrypt transaction information (e.g., account data, etc.) using a private key, TAVV, or token, etc.

[0031] A "token provisioning request message" can be an electronic message used to request a token. A token provisioning request message can include information that can be used to identify a payment account or digital wallet and / or information used to generate a payment token. For example, a token provisioning request message can include payment credentials, mobile device identification information (e.g., a phone number or MSISDN), a digital wallet identifier, information identifying a tokenization service provider, a merchant identifier, a cryptogram, and / or a digital signature, and / or any other appropriate information. Information included in a token provisioning request message can be encrypted (e.g., using a key specific to the issuer). In some embodiments, a token provisioning request message can be formatted as an authorization request message (e.g., an ISO 8583 message format). In some embodiments, a token provisioning request message can have a zero amount in the authorization amount field. As another example, a token provisioning request message can include a flag or other indicator that specifies that the message is a token provisioning request message.

[0032] A "token response message" can be a message in response to a token request. The token response message can include an indication of whether the token request was approved or declined. The token response message can also include a payment token, mobile device identification information (e.g., a phone number or MSISDN), a digital wallet identifier, a token requestor identifier, information identifying the tokenization service provider, a merchant identifier, a cryptogram, and / or a digital signature, and / or any other appropriate information. Information included in the token response message can be encrypted (e.g., using issuer-specific keys). In some embodiments, the token response message can be formatted as an authorization response message (e.g., an ISO 8583 message format). In some embodiments, the token response message can have a zero-amount in the authorized amount field. As another example, the token response message can include a flag or other indicator specifying that the message is a token response message.

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

[0034] A "resource provider" can be an entity that can provide a resource such as a good, a service, information, and / or access. Examples of resource providers include merchants, access devices, secure data access points, and the like. A "merchant" can generally be an entity that participates in a transaction and can sell or provide access to goods or services.

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

[0036] An "authorization entity" can be an entity that authorizes a request. Examples of authorization entities can be issuers, government agencies, document repositories, access administrators, and the like. An "issuer" can generally refer to a commercial entity (e.g., a bank) that maintains a user account. An issuer can also issue payment credentials to a consumer that are stored on a user device such as a cellular phone, a smart card, a tablet, or a laptop.

[0037] An "access device" can be any suitable device that provides access to a remote system. An access device can also be used to communicate with a resource provider computer. An access device can generally be located in any suitable location, such as at a location of a resource provider (e.g., a merchant). An access device can have any suitable form. Some examples of access devices include 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), kiosks, security systems, access systems, and the like. An access device can use any suitable contact or contactless mode of operation to send data to or receive data from a user mobile device or otherwise associate with a user mobile device. In some embodiments where an access device can include a POS terminal, any suitable POS terminal can be used and it can include a reader, a processor, and a computer- readable medium. A reader can include any suitable contact or contactless mode of operation. For example, an exemplary card reader can include a radio frequency (RF) antenna, an optical scanner, a bar code reader, or a magnetic stripe reader to interact with payment devices and / or mobile devices. In some embodiments, a cellular phone, tablet, or other specialized wireless device used as a POS terminal can be referred to as a mobile point of sale or "mPOS" terminal.

[0038] An "authorization request message" can be an electronic message that requests authorization for a transaction. In some embodiments, an authorization request message is sent to a transaction processing computer and / or an issuer of a payment card to request authorization for a transaction. An authorization request message according to some embodiments can comply with 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. An authorization request message can include an issuer account identifier that can be associated with a payment device or payment account. An authorization request message can also include additional data elements corresponding to "identification information," including (by way of example only): a service code, a CVV (card verification value), a dCVV (dynamic card verification value), a PAN (primary account number or "account number"), a payment token, a user name, an expiration date, and the like. An authorization request message can also include "transaction information," such as any information associated with a current transaction, such as a transaction amount, a merchant identifier, a merchant location, an acquiring bank identification number (BIN), a card acceptor ID, information identifying items being purchased, and the like, as well as any other information that can be used to determine whether to approve and / or authorize a transaction.

[0039] An "authorization response message" can be a message that responds to an authorization request. In some cases, an authorization response message can be an electronic message reply to an authorization request message generated by an issuing financial institution or a transaction processing computer. An authorization response message can include, by way of example only, one or more of the following status indicators: approved - the transaction was approved; declined - the transaction was not approved; or call center - the response depends on more information and the merchant 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 a credit card issuing bank to a merchant's access device (e.g., a POS device) indicating that a transaction was approved in response to an authorization request message in an electronic message (either directly or through a transaction processing computer). The code can be used as proof of authorization. As noted above, in some embodiments, a transaction processing computer can generate or forward an authorization response message to a merchant.

[0040] A "user device" can be an electronic device operated by a user. Examples of user devices can include mobile phones, smart phones, personal digital assistants (PDAs), laptop computers, desktop computers, server computers, vehicles such as automobiles, thin client devices, tablet PCs, and the like. In addition, a user device can be any type of wearable technology device such as a watch, earpiece, glasses, and the like. A user device can include one or more processors capable of processing user input. A user device can also include one or more input sensors for receiving user input. A user device can include any electronic device that a user can operate that can also provide remote communication capabilities with a network. Examples of remote communication capabilities include using a mobile phone (wireless) network, a wireless data network (e.g., 3G, 4G, or similar networks), Wi-Fi, Wi-Max, or any other communication medium that can provide access to a network such as the Internet or a private network.

[0041] 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 working in concert. In one example, the server computer can be a database server coupled to a Web server. The server computer can be coupled to a database and can include any hardware, software, other logic, or combination of the preceding for servicing the requests from one or more client computers. The server computer can comprise one or more computation devices and can use any of a variety of computing structures, arrangements, and compilations for servicing the requests from one or more client computers.

[0042] A "processor" can refer to any one or more appropriate data computation devices. A processor can include one or more microprocessors working together to accomplish desired functionality. A processor can include a CPU comprising at least one high-speed data processor adequate to execute program components for executing user and / or system generated requests. A CPU can be a microprocessor from AMD, such as an 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).

[0043] A "memory" can be any suitable device or devices that can store electronic data. Suitable memory can include non-transitory computer readable media that store instructions that are executable by a processor to implement a desired method. Examples of memory can include one or more memory chips, disk drives, and the like. Such memory can operate using any suitable electrical, optical, and / or magnetic modes of operation.

[0044] Details of some embodiments of the present invention will now be described.

[0045] In the field of electronic payments, it is desirable to securely communicate a customer's sensitive account information. Accordingly, many systems have introduced the use of payment tokens, which act as unique digital identifiers that replace PANs or other account information. Payment tokens (hereinafter referred to as tokens) can be used to conduct electronic transactions without exposing actual account details that can be subject to compromise. In conventional systems, a token requester (e.g., a merchant, a wallet application, a gateway, etc.) can need to be authenticated prior to provisioning a token. As is conventional, authentication can be handled by a token provider. However, the authentication effort can place a heavy computational burden on the token provider. In some cases, the token provider can not have any prior relationship with the token requester that can be leveraged in the authentication process. In conventional techniques, the token provider can additionally be required to generate and store shared secrets (e.g., TAVVs) and provide them to token requesters. This also places a computational burden on the token provider, as the token provider has to generate, manage, and provide such shared secrets to various token requesters. Embodiments of the present invention provide techniques for reducing the computational burden on the token provider.

[0046] Distribution of tokens

[0047] Prior to supplying and distributing tokens to token requestors, such requestors need to be authenticated using existing entities and infrastructure. In at least one embodiment, a registration authority (e.g., an issuer separate from the token provider and / or a payment gateway) can be used to authenticate token requestors and distribute secure credentials. In at least one embodiment, the request and distribution of secure credentials can utilize existing ISO channels.

[0048] Figure 1 This high level concept is illustrated. Figure 1 A token requestor (e.g., a merchant, a wallet application, etc.) 10, a registration authority 20 (e.g., an acquirer), and a certificate authority 30 (e.g., a payment processor and / or a token service) are illustrated. Although the certificate authority 30 and the registration authority 20 are illustrated as separate entities, in other embodiments they can be the same entity.

[0049] In step 1, the token requestor 10 can generate a public key and a private key, and can generate a certificate signing request (CSR). The CSR can include any appropriate requestor identification information and the generated public key. For example, the CSR can include a business ID / tax ID, an acquirer ID, a merchant ID (MID), a terminal ID (TID), and a public key. In some embodiments, the CSR can additionally or alternatively include a billing address, a company certificate identifier, information about a business plan, owner information, and credit limit information, etc. The token requestor 10 can transmit the CSR to the registration authority 20.

[0050] In step 2, the registration authority 20 can perform any appropriate authentication technique to authenticate the token requestor. For example, the registration authority 20 can perform a know your customer (KYC) process to authenticate the token requestor 10. A "know your customer process" can include any appropriate process for an entity to verify the identity of its customers. One purpose of a KYC process is to prevent criminals from intentionally or unintentionally using a financial institution to launder money. A KYC process can include verifying customer policies, verifying the identity of customers, monitoring customer transactions, and providing risk management. For purposes of a KYC process, a customer is intended to refer to a person or entity that holds an account with and / or has a business relationship with the entity using the KYC process. In some embodiments, an acquirer can be the registration authority 20, and a merchant that holds an account with the acquirer can be the token requestor 10. Accordingly, the acquirer can use the merchant billing address, the merchant company certificate, the merchant name or ID, owner information, or any information provided in the CSR to verify the merchant. In at least one embodiment, an acquirer is well suited to authenticate a merchant due to the ongoing business relationship between the acquirer and the merchant.

[0051] In step 3, the certificate authority 30 can receive the certificate signing request and authenticate that the request is from the registrar 20. In some examples, the certificate authority can be a payment processing network and / or a token service. The certificate authority 30 can have a direct relationship with the registrar 20 (e.g., an acquirer), but can generally not interact with the token requestor 10. Accordingly, in some embodiments, the registrar 20 can be more trusted by the certificate authority 30 than the token requestor 10. In at least one example, the certificate authority can generate a TRID (token requestor ID) and sign the CSR. The TRID can be used to provide a unique identifier for the token requestor and can include any suitable alphanumeric value. In at least one embodiment, the certificate authority 30 can maintain a mapping or other association between the token requestor's 10 TRID and public key / certificate signing request. In at least one embodiment, once the registrar 20 is authenticated and a TRID is generated, the certificate authority 30 can return a digital certificate, such as an X509 certificate, to the registrar 20. The signed CSR can also be sent with the TRID.

[0052] In step 4, the registrar 20 can return the signed certificate and TRID to the token requestor 10. Receipt of the signed certificate and TRID can inform the token requestor 10 that it can now request tokens, exchange tokens, and conduct transactions with the aid of previously obtained tokens using its private key and TRID. The TRID and the private key can be used to digitally sign subsequent transactions and / or requests provided by the token requestor 10.

[0053] Data elements and digital signatures

[0054] Embodiments of the present invention improve upon conventional techniques by shifting the generation of cryptographic keys to the token requestor (e.g., merchant, wallet application, etc.). For example, instead of requiring a token service to generate a shared secret, the token requestor can be required to generate a public / private key pair, submit a certificate signing request containing the public key, and obtain a TRID. Once the TRID is obtained, the token requestor can request tokens, exchange tokens, and / or conduct transactions with the aid of previously obtained tokens. To provide a means of securely verifying message integrity and authenticity, the token requestor can be required to digitally sign each electronic message. These techniques are simple for the token requestor to implement while still meeting security requirements. In embodiments of the present invention, the token requestor (e.g., merchant) can utilize a signed hash in each message transmitted (e.g., authorization request message, token provisioning request message, etc.).

[0055] Figure 2A diagram of a signed hash composed of data elements is shown. A token requestor (e.g., merchant) can use the signed hash as a digital signature. According to at least one embodiment, a token requestor can generate a hash value using the depicted fields. For example, a token requestor can use a token requestor ID (e.g., an RTID received from a certificate authority 30), an acquirer institution ID, a merchant ID, a terminal ID, a timestamp (e.g., in seconds), a counter, or any suitable combination of the above as input to a hash algorithm to generate a hash value. In at least one embodiment, the hash value can be signed by a token requestor private key and the generated digital signature inserted into an ISO 8583 message (e.g., an authorization request message). Figure 1

[0056] In at least one embodiment, the digital signature generated by the techniques outlined above can provide a number of advantages. For example, the digital signature can be used for authentication purposes to verify that the digital signature was generated by a token holder (e.g., merchant, wallet application, etc.). By using a digital signature over a secure channel between a token requestor (e.g., merchant), a registration authority (e.g., acquirer), a certificate authority (e.g., payment processor and / or token provider), the confidentiality of sensitive information (e.g., account number) of the token holder is maintained. The digital signature provides the ability to verify the integrity of a message (e.g., authorization request, token provisioning request message, etc.) provided by the token holder.

[0057] In at least one embodiment, the use of an incrementing counter to generate a digital signature implements a verifiable means of determining whether a received message is being repeated or replayed. For example, a message recipient (e.g., certificate authority 30, payment processor, token provider, etc.) can use the digital signature to verify that the count is incrementing. If the message recipient determines that the counter contains a value that has been previously received or is not the expected value, the message can be identified as a potentially fraudulent message (e.g., part of a replay attack).

[0058] In at least one embodiment, the use of a timestamp in the digital signature can ensure that the message has not been intercepted and / or delayed, which can further assist the message recipient in determining whether the message has been altered.

[0059] Techniques for token provisioning

[0060] Figure 3 A flow diagram illustrating a process for provisioning a token in a system including a resource provider computer 12, a transport computer 22, a token provider computer 33, and an authorization computer 40 is shown. In at least one example, the resource provider computer 12 can be implemented by a merchant, the transport computer 22 can be implemented by an acquirer, the token provider computer 33 can be implemented by a payment processor, and the authorization computer 40 can be implemented by a payment network. Figure 1 ​The token requestor 10 (e.g., merchant) operates or can act on behalf of the token requestor 10. In at least one example, the transport computer 22 can be operated by or on behalf of Figure 1 The token provider 32 (e.g., payment processing network, token provider, etc.) operates or acts on behalf of the token provider 32. In at least one example, the authorization computer 40 can be operated by or on behalf of an issuer (e.g., financial institution associated with the PAN). Figure 1 The token provider 32 (e.g., payment processing network, token provider, etc.) operates or acts on behalf of the token provider 32. In at least one example, the authorization computer 40 can be operated by or on behalf of an issuer (e.g., financial institution associated with the PAN).

[0061] In step 311, the resource provider computer 12 (merchant) obtains sensitive information (e.g., PAN) from the user device or COF data repository. The resource provider computer 12 can generate a digital signature using its private key in the manner discussed above in connection with Figure 2 The resource provider computer 12 can insert the digital signature into the token provisioning request and submit the token provisioning request message to the transport computer 22 (e.g., acquirer associated with the merchant). The token provisioning request message can also include some or all of the data elements discussed above in connection with Figure 2 In some embodiments of the application, the token provisioning request message can be in the form of an authorization request message.

[0062] In step 312, the transport computer 22 can authenticate the resource provider (e.g., merchant). For example, the transport computer 22 can extract various data fields (e.g., merchant ID, terminal ID, etc.) from the token provisioning request message. The transport computer 22 can use the extracted information to verify the resource provider against stored information (e.g., past transaction information, account data, business plans, owner information, etc.). If the extracted information of the token provisioning request message matches the stored information, the transport computer 22 can determine that the token provisioning request is authentic and that the request was initiated by the resource provider (e.g., merchant).

[0063] After authenticating the resource provider in step 312, the transport computer 22 can insert a transport ID (e.g., ACQRef from Figure 2 The token provider can use the transport ID as an indication that the transport computer 22 has authenticated the resource provider (e.g., merchant).

[0064] In step 314, the token provider computer 32 (e.g., Figure 1Upon receiving a token supply request message, the certificate authority 30 can use the TRID to look up the public key to verify the digital signature contained in the token supply request message. The TRID and public key can be stored in a data store accessible to the token provider's computer 32. In some examples, the data store is... Figure 1 The token provider computer 32 or certificate authority 30 stores the token. In at least one embodiment, the token provider computer 32 is operated by the certificate authority 30. Once the public key associated with the TRID is retrieved, the token provider computer 32 can use the public key to decrypt the digital signature. The decrypted digital signature can be used to verify the data fields of the token supply request message. If the decrypted digital signature matches the data fields of the token supply request message, then the token provider computer 32 can determine that the token supply request message is valid and has been initiated by the resource provider.

[0065] In step 315, the token provider computer 32 may generate or otherwise obtain a token. The token provider computer 32 may associate the token with a TRID and may store a record of the association. The token provider computer 32 may return the TRID and token to the delivery computer 22. In at least one embodiment, the delivery computer 22 may be configured to forward the token and TRID to the resource provider computer 12.

[0066] In step 316, the token provider computer 32 may optionally send a notification to the authorizing computer 40 (e.g., the issuer). This notification may be used to inform the issuer that a token has been generated for the PAN and supplied to a specific TRID.

[0067] As an example, a user of an electronic device can enter account information (e.g., PAN) into a webpage provided by a merchant's computer. After registering with a certificate authority as described above, the merchant's computer can exchange the PAN and a token using a token supply request message. The merchant's computer can then use the token and a digital signature generated by the merchant's computer to initiate subsequent transactions with the user. Such transactions will no longer require the PAN.

[0068] Technology for token exchange

[0069] Figure 4 A flowchart illustrating the process for exchanging tokens is shown.

[0070] In step 411, the resource provider computer 12 (operated by or on behalf of a merchant) can obtain the token and cryptogram from, for example, an electronic device (e.g., a mobile phone or a POS terminal operated by the resource provider, etc.). As an example, a wallet application operated by a consumer can submit the token and TAVV to the resource provider computer 12 as part of a financial transaction. In at least one embodiment, the resource provider computer 12 can submit the wallet token and cryptogram in a token provisioning request message with a digital signature generated by the resource provider computer 12 in accordance with the techniques discussed above. The token provisioning request can also include some or all of the data elements described as encrypted or unencrypted fields. The digital signature is discussed above with reference to Figure 2 Figure 2 The digital signature is discussed above with reference to

[0071] In step 412, the transport computer 22 can authenticate the resource provider (e.g., merchant). For example, the transport computer 22 can extract various data fields (e.g., merchant ID, terminal ID, etc.) from the token provisioning request message. The transport computer 22 can use the extracted information to verify the resource provider against stored information (e.g., past transaction information, account data, business plans, owner information, etc.). If the extracted information of the token provisioning request message matches the stored information, the transport computer 22 can determine that the token provisioning request is authentic and that the request was initiated by the resource provider (e.g., merchant).

[0072] After authenticating the resource provider in step 312, the transport computer 22 can insert a transport ID (e.g., ACQRef from Figure 2

[0073] In step 414, after the token provider computer 32 (e.g., certificate authority 30 of Figure 1 receives the token provisioning request message, it can use the TRID to look up a public key to verify the digital signature contained in the token provisioning request message. The TRID and public key can be saved in a data repository accessible to the token provider computer 32. In some examples, the data repository is maintained by Figure 1 ​​The token provider computer 32 or the certificate authority 30 maintains. In at least one embodiment, the token provider computer 32 is operated by the certificate authority 30. Once the public key associated with the TRID is retrieved, the token provider computer 32 can decrypt the digital signature with the public key. The decrypted digital signature can be used to verify the data fields of the token provisioning request message. If the decrypted digital signature matches the data fields of the token provisioning request message, the token provider computer 32 can determine that the token provisioning request message is valid and has been initiated by the resource provider. The token provider computer 32 can further verify that the cryptogram (e.g., the wallet token) has been provisioned to the wallet application. Accordingly, the token provider computer 32 can authenticate both the customer (operating the electronic device) and the merchant.

[0074] In step 415, the token provider computer 32 can generate or otherwise obtain a second token. The token provider computer 32 can associate the second token with the TRID and can maintain a record of the association. The token provider computer 32 can return the TRID and the second token to the transport computer 22. In at least one embodiment, the transport computer 22 can be configured to forward the token and the TRID to the resource provider computer 12.

[0075] In step 416, the token provider computer 32 can optionally send a notification to the authorization computer 40 (e.g., the issuer). The notification can be used to inform the issuer that the second token was generated for the PAN and provisioned to the particular TRID.

[0076] In at least one embodiment, a resource provider (e.g., a merchant) can obtain its own token or accept tokens from other token domains. For example, a merchant can obtain a token directly from a token provider and can also accept a token from a wallet application. In some instances, the token generated by the token provider can be associated with a different token domain than the token provided by the wallet application. It can be desirable for the resource provider to exchange the token provided by the wallet for the token generated by the token provider for the merchant. The process discussed above in connection with FIG. 4 can be used to accomplish this goal. Figure 4

[0077] ​As an example, a user of an electronic device (e.g., a consumer) can initiate a transaction through a wallet application running on the electronic device. In at least one example, the wallet application can submit token information (e.g., a token stored by the wallet application, hereinafter referred to as a "wallet token") through a merchant's POS terminal. The wallet application (or the POS terminal) can submit the wallet token to a merchant computer (e.g., an example of resource provider computer 12). In at least one example, a cryptogram (e.g., a TAVV) can be included in the token information and submitted with the wallet token. The merchant computer can exchange the wallet token for a new token associated with the merchant using a token provisioning request message after being registered with a certificate authority (e.g., a payment processing network, a token provider, etc.) as discussed above in connection with Figure 1 Figure 2 The merchant computer can insert the wallet token (in some cases, a TAVV) and a digital signature generated by the merchant computer into a token provisioning request message according to the processes described in connection with

[0078] Subsequent transactions initiated by the user can be conducted by the merchant computer using the new token and a digital signature generated by the merchant computer. Such transactions will no longer require inclusion of the wallet token.

[0079] Crossing Different Token Domains

[0080] In the above use case, the consumer can be initiating a transaction with a cryptogram from a trusted entity (SE, HCE) and must generate a new token to cross token domains. In at least one embodiment, the token provider computer 32 can enforce domain restrictions to ensure that higher security tokens (e.g., SE and / or HCE) are not exchanged for lower security tokens (e.g., COF). For example, the following table illustrates how tokens can be exchanged.

[0081]

[0082]

[0083] Figure 5 A flowchart illustrating a token processing flow is shown.

[0084] In step 511, the resource provider computer 12 (operated by or on behalf of a merchant) can obtain the archived token and can submit a merchant initiated transaction (MIT) including a digital signature generated by the resource provider computer 12. The MIT can be formatted as an authorization request message that can include some or all of the data elements discussed above as encrypted and / or unencrypted data fields. Figure 2

[0085] ​​In step 512, the transmitting computer 22 (e.g., the acquiring party) can authenticate the resource provider. For example, the transmitting computer 22 can extract the Merchant ID and Terminal ID from the MIT / Authorization Request message and compare the extracted information with stored information associated with the resource provider. It should be recognized that although MID and TID are used to authenticate the merchant in this example, any appropriate data contained in the MIT / Authorization Request message can be used similarly.

[0086] In step 513, if the MID and TID (or appropriate extracted data) match the stored data associated with the resource provider, then the transfer computer 22 can insert the transfer ID (e.g., Figure 2 The ACQRef is then sent to provide an indication that the resource provider has been authenticated. The transmitting computer 22 may then forward the MIT / Authorization Request message to the token provider computer 32 (e.g., operated by or on behalf of the payment processing network).

[0087] In step 514, the token provider computer 32 can use the received TRID to look up the public key to verify the digital signature contained in the MIT / Authorization Request message. If the data contained in the decrypted digital signature matches the corresponding data field of the MIT / Authorization Request message, then the token provider computer 32 can perform a token-to-PAN translation and replace the token with the corresponding PAN in the MIT / Authorization Request message.

[0088] In step 515, the authorization request process continues as the token provider computer 32 forwards the authorization request message containing the PAN to the authorization computer 40 (e.g., the issuer associated with the PAN). In step 516, the authorization computer 40 can, as follows: Figure 5 The authorization response message (e.g., approval or rejection of the transaction) is returned to the resource provider computer 12 via the token provider computer 32 and the transmission computer 22. In at least one embodiment, the PAN can be translated back into a token in the authorization response message at the token provider computer 32.

[0089] At the end of the day or at another appropriate time, a clearing and settlement process may take place between the authorized computer 40 and the transmission computer 22.

[0090] Considerations for Limited Token Addressing Space

[0091] Figure 6 The illustration shows the reuse of tokens within a token domain.

[0092] By narrowing the domain restriction to the resource provider level (e.g., merchant level), the compromise can be greatly contained because the token can only be used at a specific resource provider. However, a large token space can be necessary. In some embodiments, it is possible to assign #PAN X# merchants.

[0093] If the number of tokens exceeds the available space, it is possible to reuse tokens within the token domain (COF). The techniques described herein enable tokens to be reused by requiring the resource provider to provide a digital signature with each message. Because the token requires a digital signature to function, it is possible to revoke the certificate of the affected resource provider without hindering the use of tokens by other resource providers.

[0094] Figure 7 A diagram illustrating an environment in which tokens are reused within a token domain is shown. In Figure 7 In the example shown, a gateway computer can act as a token requester on behalf of one or more resource providers (e.g., merchants). The gateway can receive a CSR from a resource provider and submit a token provisioning request message on behalf of the resource provider in a similar manner as described above. Once a token is issued by the token provider (e.g., token provider computer 32 issues a token via a transport computer), the gateway can issue a unique gateway token to the resource provider. The gateway can use the same token provided by the token provider for multiple resource providers, providing messages (e.g., authorization request messages) on behalf of the resource providers. If a compromise is determined, the certificate corresponding to the affected resource provider can be revoked without affecting the transactions of unaffected resource providers. By enabling a single token (token provider token) to be reused on behalf of multiple resource providers, the available token space can be used optimally.

[0095] Figure 8 A diagram illustrating an environment in which resource providers use unique tokens is shown. In Figure 8 In the example shown, a gateway computer can act as a token requester on behalf of one or more resource providers (e.g., merchants). The gateway can receive and maintain a unique certificate for each resource provider. In at least one embodiment, the gateway can sign each transaction originating from a particular resource provider with the certificate uniquely assigned to that particular resource provider.

[0096] Routing to multiple registration authorities

[0097] Figure 9 A diagram illustrating reuse of token requester IDs is shown.

[0098] After obtaining a token (e.g., from a token provider computer 32), a resource provider can wish to route a transaction via a different transport computer (e.g., operated by or on behalf of a different acquirer) because the resource provider can be operating globally in different countries. The resource provider (or a gateway signing messages on behalf of the resource provider) can need to register with each transport computer through which they wish to route their tokens. Figure 9 The relationship between a token requestor (e.g., a resource provider computer associated with a merchant) and multiple transport computers is shown. It should be recognized that, Figure 9 The transport computers shown are intended to be illustrative of transport computers operated by different entities.

[0099] Figure 10 A diagram illustrating a registration matching process is shown.

[0100] In step 1, a token requestor 10 can register with a registration authority 50. The entity operating the registration authority 50 can be different than the entity operating the registration authority 20. Figure 1 In at least one embodiment, the token requestor 10 generates a public / private key pair and a CSR as described above. The CSR can be sent to the registration authority 50. The CSR can contain information such as (but not limited to) merchant name, business ID / tax ID, acquirer ID, merchant ID (MID), terminal ID, and public key.

[0101] In step 2, the registration authority 50 can authenticate the token requestor in a similar manner as described above in connection with the registration authority 20. Figure 1

[0102] In step 3, a certificate authority 30 can receive the CSR from the registration authority 50. In at least one embodiment, the certificate authority 30 can authenticate that the CSR is from the registration authority 50 and verify that the information contained in the CSR matches the information contained in a previous registration (e.g., a previously received CSR associated with the token requestor 10). If the information matches the previous registration, the certificate authority 30 can return an approval indication in step 4. The approval can be returned to the token requestor 10 via the registration authority 50 in a similar manner as described above in connection with the certificate authority 20. Figure 1

[0103] Technical Advantages

[0104] ​​Embodiments of the present invention alleviate the computational burden of the token provider by delegating the authentication effort to other entities (e.g., acquirers), i.e., effectively leveraging the pre-existing relationship between the registration authority (e.g., acquirer) and the token requester (e.g., merchant). Furthermore, the secret key generation effort is delegated to the token requester (e.g., merchant), which further alleviates the computational burden of the token provider. Embodiments of the present invention ensure that the entity submitting the token transaction enjoys the power or ownership of the token. By leveraging the techniques described herein, the confidentiality of sensitive data is maintained. By leveraging the token and digital signature described herein, the integrity of the message can be verified. Since the digital signature described herein is generated using the specific data fields described above, fraudulent transactions (e.g., replay attacks, impersonation, reordering of messages, insertion / deletion of messages, etc.) can be detected. Accordingly, tokens can be provisioned and distributed to the token provider at a lower computational cost.

[0105] The various participants and elements described herein can operate one or more computer devices to facilitate the functionality described herein. Any of the elements described above, including any servers or databases, can use any suitable number of subsystems to facilitate the functionality described herein. Figure 1

[0106] It should be understood that the present invention, as described above, can be implemented in the form of control logic using computer software in a modular or integrated manner. Based on the disclosure and teachings provided herein, a person of ordinary skill in the art will know and appreciate other ways and / or methods to implement the present invention using hardware and a combination of hardware and software. Any of the entities mentioned above can operate a computer programmed to perform the functions described herein.

[0107] Examples of such subsystems or components can be interconnected via a system bus. Additional subsystems such as a printer, keyboard, fixed disk (or other memory comprising computer readable media), monitor, which is coupled to display adapter, and others can also be connected to the computer system. Peripherals and input / output (I / O) devices, which can be connected to the computer system, can be connected to an I / O controller (which can be a processor or other suitable controller) via any means, such as a serial port. For example, a serial port or other interface can be used to connect the computer system to a wide area network such as the Internet, to a mouse input device, or to a scanner. The interconnection via system bus allows the central processor to communicate with each subsystem and to control the execution of instructions from system memory or the fixed disk, as well as the exchange of information between subsystems. The system memory and / or the fixed disk can embody a computer readable medium.

[0108] ​Any of the software components or functions described in this application can be implemented as software code to be executed by a processor using, for example, conventional or object-oriented techniques. The software code can be stored as a series of instructions or commands or as a series of codes 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 a floppy disk, or an optical medium such as an optical disk. 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.

[0109] Different arrangements of the components depicted in the drawings and / or described above can be possible, as can different arrangements of steps of the methods described above and / or depicted in the drawings. Similarly, some features and sub-combinations can be used, even if they are not explicitly described or illustrated. Embodiments of the application have been described for illustrative and not exclusive or exhaustive purposes. Accordingly, alternative embodiments of the application will be apparent to those of ordinary skill in the art in view of this disclosure. Therefore, although the application has been described with reference to specific embodiments, it will be recognized that the application is not limited thereto and that there are many alternatives, modifications, permutations and equivalents. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense.

[0110] Additional Embodiments

[0111] Another embodiment of the application relates to a method for providing secure token-based transactions. The method can include generating a certificate signing request at a resource provider computer. The method can also include transmitting the certificate signing request to a registration authority computer. In at least one embodiment, receiving the certificate signing request can cause the registration authority computer to authenticate a resource provider associated with the resource provider computer. The method can also include receiving a token requestor identifier (ID) and a signing certificate from the registration authority computer, the token requestor ID and the signing certificate being assigned to the resource provider. In some embodiments, the method can also include storing the token requestor ID. In at least one embodiment, a token requestor computer can utilize the token requestor ID to generate a digital signature for a subsequent token-based transaction.

[0112] Another embodiment of the invention relates to a resource provider computer comprising a processor and a computer readable medium coupled to the processor, the computer readable medium comprising code executable by the processor for implementing a method. The method can comprise generating a certificate signing request. The method can also comprise transmitting the certificate signing request to an enrollment authority computer. In at least one embodiment, receipt of the certificate signing request can cause the enrollment authority computer to authenticate a resource provider associated with the resource provider computer. The method can also comprise receiving a token requestor identifier (ID) and a signing certificate, the token requestor ID and signing certificate assigned to the resource provider. In some embodiments, the method can also comprise storing the token requestor ID. In at least one embodiment, a token requestor computer can utilize the token requestor ID to generate digital signatures for future token-based transactions.

[0113] Another embodiment of the invention relates to a method comprising receiving a first payment token. The method can also comprise transmitting a token request message to a token service computer using the first payment token, wherein the token service computer generates a second payment token in response to receiving the first payment token. The method can also comprise receiving the second payment token from the token service computer. In at least one embodiment, the first payment token can be associated with a first token domain, and the second payment token can be associated with a second token domain. In at least one embodiment, the first token domain can be associated with a security restriction that is the same as or lower than the second token domain. In at least one embodiment, the second payment token is a card-on-file (COF) token associated with a resource provider (e.g., a merchant). In at least one embodiment, the method can also comprise receiving an authorization request message comprising the first payment token (e.g., by an enrollment authority computer), modifying the authorization request message by employing the second payment token in place of the first payment token, and transmitting the modified authorization request message to a payment processing computer. In at least one embodiment, the token provisioning request message can be routed through a transport computer before being received by a token provider computer. In some embodiments, the transport computer can authenticate the resource provider. In at least one embodiment, the token provisioning request message comprises the first payment token, a cryptogram associated with the first payment token, and a digital signature generated by the resource provider computer. In at least one embodiment, the token provider computer can generate a token requestor identifier for the resource provider and provide the token requestor identifier along with the second payment token. In at least one embodiment, the resource provider computer can utilize the token requestor identifier to provide digital signatures in future authorization request messages.

Claims

1. A computer-implemented method comprising: for a user requesting to interact with a token requestor, receiving, at an enrollment computer, a certificate signing request from a token requestor computer associated with the token requestor; in response to receiving the certificate signing request, authenticating, by the enrollment computer, the token requestor; adding, to the certificate signing request, an indication that the token requestor has been authenticated by the enrollment computer; sending, by the enrollment computer, the certificate signing request including the indication to a certificate authority computer, the certificate authority computer being remote to the enrollment computer; receiving, by the enrollment computer, from the certificate authority computer, a token requestor identifier (ID) for the token requestor; sending, by the enrollment computer, the token requestor ID to the token requestor computer; receiving, by the enrollment computer, from the token requestor computer, an authorization request message including a token obtained by the token requestor using the token requestor ID, wherein the token includes a payment account identifier as a substitute for an account number of the user requesting to interact with the token requestor, wherein the payment account identifier is provided in the authorization request message in place of the account number of the user; and sending, by the enrollment computer, the authorization request message including the token to the certificate authority computer, wherein receiving the authorization request message causes the certificate authority computer to convert the payment account identifier of the token to the account number of the user, wherein the token is a first token, and the method further comprises: sending, by the enrollment computer, to the certificate authority computer, a token request message using the first token; receiving, by the enrollment computer, from the certificate authority computer, a second token; and sending, by the enrollment computer, to the token requestor computer, the second token for use in subsequent token-based transactions.

2. The computer-implemented method of claim 1, wherein authenticating the token requestor comprises performing a process for verifying an identity of the token requestor.

3. The computer-implemented method of claim 1, wherein receiving the certificate signing request causes the certificate authority computer to: verify that the enrollment computer has authenticated the token requestor based at least in part on determining that an identifier associated with the enrollment computer is included in the certificate signing request; generate the token requestor ID for the token requestor in response to verifying that the enrollment computer has authenticated the token requestor; and store a mapping between the token requestor ID and a public key generated by and received from the token requestor computer.

4. The computer-implemented method of claim 1, further comprising: ​ receiving, by the registrar computer from the token requestor computer, a token provisioning request message prior to receiving the authorization request message from the token requestor computer by the registrar computer, the token provisioning request message including the token requestor ID, a digital signature generated by the token requestor computer using the token requestor ID, and information indicating that a message is the token provisioning request message; sending, by the registrar computer, the token provisioning request message to the certificate authority computer, wherein receiving the token provisioning request message causes the certificate authority computer to retrieve a public key associated with the token requestor ID and use the public key to verify the digital signature; in response to the digital signature being verified, receiving, by the registrar computer from the certificate authority computer, a token response message, the token response message including the first token issued to the token requestor and information indicating that a message is the token response message in response to the token provisioning request message; and sending the first token to the token requestor computer.

5. The computer-implemented method of claim 4, wherein the token provisioning request message further includes an identifier associated with the registrar computer, a terminal identifier, a timestamp, and a message counter.

6. The computer-implemented method of claim 4, further comprising notifying an authorization computer that the first token has been provisioned to the token requestor, the authorization computer associated with the account of the user.

7. The computer-implemented method of claim 4, wherein receiving the token provisioning request message causes the certificate authority computer to decrypt the digital signature to generate decrypted information and compare the decrypted information to one or more data fields of the token provisioning request message.

8. The computer-implemented method of claim 1, further comprising: receiving, by the registrar computer, an authorization response message corresponding to the authorization request message; and sending, by the registrar computer to the token requestor computer, the authorization response message.

9. A registrar computer comprising: a processor; and a non-transitory computer-readable storage medium storing code that, when executed by the processor, causes the processor to perform a method comprising: receiving, from a token requestor computer associated with a token requestor, a certificate signing request for a user requesting to interact with the token requestor; authenticating the token requestor in response to receiving the certificate signing request; adding an indication to the certificate signing request that the token requestor is authenticated; sending the certificate signing request including the indication to a certificate authority computer, the certificate authority computer remote to the registrar computer; receiving, from the certificate authority computer, a token requestor identifier (ID) for the token requestor; sending the token requestor ID to the token requestor computer; ​ ​ ​ receiving an authorization request message from the token requestor computer, the authorization request message including a token obtained by the token requestor using the token requestor ID, wherein the token includes a payment account identifier as a substitute for an account number of the user requesting the interaction with the token requestor, wherein the payment account identifier is provided in the authorization request message in place of the account number of the user; and sending the authorization request message including the token to the certificate authority computer, wherein receiving the authorization request message causes the certificate authority computer to convert the payment account identifier of the token to the account number of the user, wherein the token is a first token, and the method further comprises: sending a token request message to the certificate authority computer using the first token; receiving a second token from the certificate authority computer; and sending the second token to the token requestor computer for use in subsequent token-based transactions.

10. The registration authority computer of claim 9, wherein the token requestor ID is generated by the certificate authority computer in response to receiving the certificate signing request from the registration authority computer.

11. The registration authority computer of claim 9, wherein the certificate signing request is received and sent within the authorization request message in compliance with the ISO 8583 transaction message format.

12. The registration authority computer of claim 9, wherein the method further comprises notifying an authorization computer that the first token has been provisioned to the token requestor, the authorization computer being associated with an issuer corresponding to the account number of the user.

13. The registration authority computer of claim 9, wherein the method further comprises: prior to receiving the authorization request message from the token requestor computer, receiving a token provisioning request message, the token provisioning request message including the token requestor ID, a digital signature generated by the token requestor computer using the token requestor ID, and information indicating that the message is the token provisioning request message; and sending the token provisioning request message to the certificate authority computer, wherein receiving the token provisioning request message causes the certificate authority computer to obtain a public key associated with the token requestor ID and use the public key to verify the digital signature.

14. The registration authority computer of claim 9, wherein the token provisioning request message is transmitted through a transit computer prior to being received by the certificate authority computer, and wherein the transit computer authenticates an identity of the token requestor associated with the token provisioning request message.

15. The registration authority computer of claim 9, wherein the second token is associated with a second token domain, and wherein the first token is associated with a first token domain, the first token domain being associated with fewer security restrictions than the second token domain.

16. The registration authority computer of claim 9, wherein an identifier associated with the registration authority computer is added to the certificate signing request as an indication to the certificate authority computer that the registration authority computer has authenticated the token requestor.

17. The registration authority computer of claim 9, wherein the token requestor ID is received in response to sending the certificate signing request to the certificate authority computer.

18. The registration authority computer of claim 9, wherein the certificate signing request includes a public key associated with the token requestor, and wherein the certificate authority computer is configured to maintain a mapping between the token requestor ID generated for the token requestor and the public key of the token requestor.

Images