WO2025071597A1

WO2025071597A1 - Tokenized interactions using electronic identifier

Info

Publication number: WO2025071597A1
Application number: PCT/US2023/075272
Authority: WO
Inventors: Yuexi Chen; Sonia Gupta; Ratna Deepthi JARUGU
Original assignee: Visa International Service Association
Current assignee: Visa International Service Association
Priority date: 2023-09-27
Filing date: 2023-09-27
Publication date: 2025-04-03
Anticipated expiration: 2026-03-27

Abstract

A method is disclosed. The method includes an access device receiving a communication comprising electronic ID information from a user device in a transaction. The access device transmits an electronic ID authentication request message to an electronic ID access control computer and receives an electronic ID authentication response message from the electronic ID access control computer. In response to receiving the electronic ID authentication response message, the access device transmits a token request message to a token service computer and receives a token response message comprising a token from the token service computer. The access device the generates an authorization request message comprising the token and a value and transmits the authorization request message comprising the token to a processing computer. The processing computer processes the transaction using the using the token.

Description

PATENT Attorney Docket No.: 079900-1395618 Client Reference No.: 7160WO01 TOKENIZED INTERACTIONS USING ELECTRONIC IDENTIFIER CROSS-REFERENCES TO RELATED APPLICATIONS [0001] None. BACKGROUND [0002] An electronic identification can include a digital solution for proof of identity of citizens or organizations. They can be used to view to access certain benefits or services. Some have contemplated using them for payment transactions. However, an electronic identification can include a combination of information such as an identification number, a digital signature, photos, etc. Such information cannot be used in existing transaction systems such as payment systems, since the payment systems have messages that are pre-formatted. As such, the ability to use electronic identifications for transactions such as payment transactions is very limited. Additionally, passing electronic identification information through computer networks and though many nodes could expose it to potential hacking and man-in- the middle attacks. Also, many entities do not wish to handle sensitive electronic identification information, as extensive security protocols would need to be implemented. [0003] Embodiments of the disclosure address this problem and other problems individually and collectively. SUMMARY [0004] One embodiment is related to a method comprising: receiving, by an access device comprising an electronic ID control module and a transaction processing module, a communication comprising electronic ID information from a user device in a transaction, transmitting, by the access device, an electronic ID authentication request message to an electronic ID access control computer, receiving, by the access device, an electronic ID authentication response message from the electronic ID access control computer, in response to receiving the electronic ID authentication response message, transmitting, by the access device, a 1 77627443V.1 PATENT Attorney Docket No.: 079900-1395618 Client Reference No.: 7160WO01 token request message to a token service computer, receiving, by the access device, a token response message comprising a token from the token service computer, generating, by the access device, an authorization request message comprising the token and a value, and transmitting, by the access device, the authorization request message comprising the token to a processing computer, which processes the transaction using the using the token. [0005] Another embodiment is related to an access device comprising: a processor, an electronic ID control module, a transaction processing module, and a computer readable medium, the computer readable medium comprising code executable by the processor to cause the processor to perform operations including: receiving a communication comprising electronic ID information from a user device in a transaction; transmitting an electronic ID authentication request message to an electronic ID access control computer; receiving an electronic ID authentication response message from the electronic ID access control computer; in response to receiving the electronic ID authentication response message, transmitting a token request message to a token service computer; receiving a token response message comprising a token from the token service computer; generating an authorization request message comprising the token and a value; and transmitting the authorization request message comprising the token to a processing computer, which processes the transaction using the using the token. [0006] Another embodiment is related to a method comprising: receiving, by an access device, a communication comprising electronic ID information from a user device in a transaction; transmitting, by the access device, an electronic ID authentication request message to an electronic ID access control computer; receiving, by the access device, an electronic ID authentication response message from the electronic ID access control computer; in response to receiving the electronic ID authentication response message, transmitting, by the access device, a registration request message to a token service computer, which stores an association between a token and the user device. [0007] A better understanding of the nature and advantages of embodiments of the invention may be gained with reference to the following detailed description and accompanying drawings. 2 77627443V.1 PATENT Attorney Docket No.: 079900-1395618 Client Reference No.: 7160WO01 BRIEF DESCRIPTION OF THE DRAWINGS [0008] FIG.1 shows a block diagram of a system and method for registering an electronic ID for use in a transaction system, according to embodiments. [0009] FIG.2 shows a block diagram of a system and method for using an electronic ID within a transaction system, according to embodiments. [0010] FIG.3 shows a block diagram of components of an access device according to embodiments. [0011] FIG.4 shows a block diagram of components of a token service computer according to embodiments. DETAILED DESCRIPTION [0012] Prior to discussing embodiments of the disclosure, some terms can be described in further detail. [0013] A “user” may include an individual. In some embodiments, a user may be associated with one or more personal accounts and/or mobile devices. The user may also be referred to as a cardholder, account holder, or consumer in some embodiments. [0014] A “user device” may be a device that is operated by a user. Examples of user devices may include an electronic ID, mobile phone, a smart phone, a card, a personal digital assistant (PDA), a laptop computer, a tablet PC, etc. Additionally, user devices may be any type of wearable technology device, such as a watch, earpiece, rings, bracelets, glasses, a vehicle such as an electric vehicle, 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. 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 3 77627443V.1 PATENT Attorney Docket No.: 079900-1395618 Client Reference No.: 7160WO01 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. A user device may also be a payment device such as a credit, debit, or prepaid card. [0015] An “electronic identification,” also referred to as “electronic ID” or an “eID,” may be a digital proof of identity. An electronic ID can serve as an identification tool for individuals or organizations. An electronic ID can be a physical item usable for both online and offline personal identification or authentication. An electronic ID can include identity information that can be used to authenticate the identity of the electronic ID’s owner. The identity information can be visually displayed and/or digitally encoded on the electronic ID. For example, an electronic ID can include printed or embossed identity information such as an identification number (e.g., a passport number, license number, or badge number), name, address, age, date of birth, place of birth, weight, eye color, nationality, ethnicity, expiration date, issue date, a photograph, and/or and other suitable printed personal details. The identification number is also referred to as a serial number. The electronic ID can also include a contact element, a contactless element (e.g., RFID microchip) or any other suitable processor, memory, and/or antenna. The memory may contain digital versions of some or all of the printed identity information, a digital certificate, one or more encryption keys, and/or one or more biometric templates (e.g., fingerprint templates, facial recognition templates, iris templates, etc.) or other data for biometric verification. Examples of electronic IDs include an electronic passport (“ePassport”) and electronic identification card (e.g., e-Driving license, smart card). An electronic ID may be issued by a government authority. [0016] An “interaction” may include a reciprocal action or influence. An interaction can include a communication, contact, or exchange between parties, devices, and/or entities. Example interactions include a transaction between two parties and a data exchange between two devices. In some embodiments, an interaction can include an identity interaction in which two devices interact to authenticate an identity. In some embodiments, an interaction can include a payment transaction in which two devices can interact to facilitate a payment. 4 77627443V.1 PATENT Attorney Docket No.: 079900-1395618 Client Reference No.: 7160WO01 [0017] “Interaction data” can include data related to and/or recorded during an interaction. In some embodiments, interaction data can be transaction data or network data. Transaction data can comprise a plurality of data elements with data values. [0018] “Credentials” may comprise any evidence of authority, rights, or entitlement to privileges. For example, access credentials may comprise permissions to access certain tangible or intangible assets, such as a building or a file. Examples of credentials may include passwords, account numbers, passcodes, or secret messages. [0019] “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 CVV 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 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. [0020] A “token” may be a substitute value for a credential. A token may be a string of numbers, letters, or any other suitable characters. Examples of tokens include payment tokens, access tokens, personal identification tokens, etc. [0021] 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). For example, a payment token may include a series of alphanumeric characters that may be used as a substitute for an original account identifier. For example, a token 5 77627443V.1 PATENT Attorney Docket No.: 079900-1395618 Client Reference No.: 7160WO01 “4900000000000001” may be used in place of a PAN “4147090000001234.” In some embodiments, a payment 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 payment 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 payment token 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. [0022] “Tokenization” is a process by which data is replaced with substitute data. For example, a payment account identifier (e.g., a primary account number (PAN)) may be tokenized by replacing the primary account identifier with a substitute number (e.g., a token) that may be associated with the payment account identifier. Further, tokenization may be applied to any other information that may be replaced with a substitute value (i.e., token). Tokenization enhances transaction efficiency and security. [0023] A “token issuer,” token provider,” “token service system,” or “token service computer” can include a system that services tokens. In some embodiments, a token service system 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 system may establish a token assurance level for a given token to indicate the confidence level of the token to PAN binding. The token service system may include or be in communication with a token vault where the generated tokens are stored. The token service system may support token processing of payment transactions submitted using tokens by de-tokenizing the tokens to obtain the actual PANs. In some embodiments, a token service system may include a tokenization computer alone, or in combination with other computers such as a transaction processing network computer. Various entities of a 6 77627443V.1 PATENT Attorney Docket No.: 079900-1395618 Client Reference No.: 7160WO01 tokenization ecosystem may assume the roles of the token service provider. For example, payment networks and issuers or their agents may become the token service provider by implementing the token services according to embodiments of the present invention. [0024] A “token domain” may indicate an area and/or circumstance in which a token can be used. Examples of token domains 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 provider 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. [0025] A “token cryptogram” may include a token authentication verification value (TAVV) associated with a token. A token cryptogram may be a string of numbers, letters, or any other suitable characters, of any suitable length. In some embodiments, a token cryptogram may include encrypted token data associated with a token (e.g., a token domain, a token expiry date, etc.). For example, a token cryptogram may be used to validate that the token is being used within a token domain and/or by a token expiry date associated with the token. [0026] “Token data” can include information related to a token. Token data can include a token and/or a token cryptogram. In some embodiments, token data can include only a token. In other embodiments, token data can include only a token cryptogram. In yet other embodiments, token data can include a token and a token cryptogram that is related to the token. Token data can include additional data related to the token (e.g., a token expiry date, etc.). 7 77627443V.1 PATENT Attorney Docket No.: 079900-1395618 Client Reference No.: 7160WO01 [0027] A “token expiry date” can include an 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. [0028] A “token request message” may be an electronic message for requesting token data. A token request message can request token data including a token and/or a token cryptogram. A token request message may include information usable for identifying an identity account or identity record, a payment account or digital wallet, and/or information for generating a payment token. For example, a token request message may 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 token cryptogram, information related to an electronic ID or authentication of an electronic ID, and/or any other suitable information. Information included in a token request message can be encrypted (e.g., with an issuer-specific key). [0029] A “token response message” may be a message that responds to a token request. A token response message may include an indication that a token request was approved or denied. A token response message may also include a payment token, 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 token cryptogram, and/or any other suitable information. Information included in a token response message can be encrypted (e.g., with an issuer-specific key). [0030] A “token requestor identifier” may include any characters, numerals, or other identifiers associated with an entity associated with a network token system. For example, a token requestor identifier may be associated with an entity that is registered with the network token system. In some embodiments, a unique token requestor identifier may be assigned for each domain for a token request associated with the same token requestor. For example, a token requestor identifier can identify 8 77627443V.1 PATENT Attorney Docket No.: 079900-1395618 Client Reference No.: 7160WO01 a pairing of a token requestor (e.g., a mobile device, a mobile wallet provider, etc.) with a token domain (e.g., e-commerce, contactless, etc.). A token requestor identifier may include any format or type of information. For example, in one embodiment, the token requestor identifier may include a numerical value such as a ten digit or an eleven-digit number (e.g., 4678012345). [0031] An “amount” can include a quantity of something. An amount can include a total of a thing or things in number, size, value, or extent. [0032] A “resource provider” may be an entity that can provide a resource such as goods, services, information, and/or access. Examples of resource providers includes merchants, data providers, transit agencies, governmental entities, venue and dwelling operators, etc. [0033] The term "authentication" and its derivatives may include a process by which the credential of an endpoint (including but not limited to applications, people, devices, processes, and systems) can be verified to ensure that the endpoint is who they are declared to be. [0034] The term "verification" and its derivatives may include a process that utilizes information to determine whether an underlying subject is valid under a given set of circumstances. Verification may include any comparison of information to ensure some data or information is correct, valid, accurate, legitimate, and/or in good standing. [0035] A “key” may include a piece of information that is used in a cryptographic algorithm to transform input data into another representation. A cryptographic algorithm can be an encryption algorithm that transforms original data into an alternate representation, or a decryption algorithm that transforms encrypted information back to the original data. Examples of cryptographic algorithms may include triple data encryption standard (TDES), data encryption standard (DES), advanced encryption standard (AES), etc. [0036] A "public key" may include an encryption key that may be shared openly and publicly. The public key may be designed to be shared and may be configured such that any information encrypted with the public key may only be 9 77627443V.1 PATENT Attorney Docket No.: 079900-1395618 Client Reference No.: 7160WO01 decrypted using a private key associated with the public key (i.e., a public/private key pair). [0037] A "private key" may include any encryption key that may be protected and secure. A private key may be securely stored at an entity and may be used to decrypt any information that has been encrypted with an associated public key of a public/private key pair associated with the private key. [0038] A “public/private key pair” may refer to a pair of linked cryptographic keys generated by an entity. The public key may be used for public functions such as encrypting a message to send to the entity or for verifying a digital signature which was supposedly made by the entity. The private key, on the other hand may be used for private functions such as decrypting a received message or applying a digital signature. In some embodiments, the public key may be authorized by a body known as a Certification Authority (CA) which stores the public key in a database and distributes it to any other entity which requests it. The private key can typically be kept in a secure storage medium and will usually only be known to the entity. Public and private keys may be in any suitable format, including those based on Rivest- Shamir-Adleman (RSA) or elliptic curve cryptography (ECC). [0039] A “zone encryption key” (ZEK) can include cryptographic keys used to encrypt data between two specific points. For example, zone encryption keys can be used to encrypt data transmitted between a first device and a second device. [0040] A "digital signature" may include a type of electronic signature. A digital signature may encrypt documents with digital codes that can be difficult to duplicate. In some embodiments, a digital signature may refer to the result of applying an algorithm based on a public/private key pair, which allows a signing party to manifest, and a verifying party to verify, the authenticity and integrity of a document. The signing party acts by means of the private key and the verifying party acts by means of the public key. This process certifies the authenticity of the sender, the integrity of the signed document and the so-called principle of nonrepudiation, which does not allow disowning what has been signed. A certificate or other data that includes a digital signature by a signing party is said to be "signed" by the signing party. 10 77627443V.1 PATENT Attorney Docket No.: 079900-1395618 Client Reference No.: 7160WO01 [0041] A "certificate" or "digital certificate" may include an electronic document and/or data file. In some cases, the certificate or the digital certificate may be a device certificate. In some embodiments, a digital certificate may use a digital signature to bind a public key with data associated with an identity. A digital certificate may be used to prove the ownership of a public key. The certificate may include one or more data fields, such as the legal name of the identity, a serial number of the certificate, a valid-from and valid-to date for the certificate, certificate related permissions, etc. A certificate may contain a "valid-from" date indicating the first date the certificate is valid, and a "valid-to" date indicating the last date the certificate is valid. A certificate may also contain a hash of the data in the certificate including the data fields. A certificate can be signed by a certificate authority. The certificate or digital certificate can also include interaction data such as one or more access device identifiers, one or more user device identifiers (e.g., VIN numbers), a timestamp of when the certificate was created, a validity period, an authentication computer public key, etc. [0042] A "certificate authority" may include an entity that issues digital certificates. A certificate authority may prove its identity using a certificate authority certificate, which includes the certificate authority’s public key. A certificate authority certificate may be signed by another certificate authority’s private key or may be signed by the same certificate authority’s private key. The latter is known as a self- signed certificate. The certificate authority may maintain a database of all certificates issued by the certificate authority. The certificate authority may maintain a list of revoked certificates. The certificate authority may be operated by an entity, for example, a processing network entity, an issuer, an acquirer, a central bank etc. In some cases, a certificate authority can maintain an authentication computer. [0043] A “electronic ID authentication request message” may be an electronic message for requesting authentication of an electronic ID. In some embodiments, it is sent to an electronic ID access control computer to request authentication of the electronic ID. An electronic ID authentication request message may comprise electronic ID information, which can include various data elements provided by an electronic ID. For example, electronic ID information can include data elements such as an identification number (e.g., license number, passport number), user data (e.g., 11 77627443V.1 PATENT Attorney Docket No.: 079900-1395618 Client Reference No.: 7160WO01 name, age, address, date of birth), biometric verification data, and/or any other suitable information digitally encoded on the electronic ID. An electronic ID authentication request message can include a cryptogram and/or a digital signature generated by the electronic ID, and which may be generated using dynamic input data such as a counter, timestamp, and/or challenge value (e.g., a nonce), which also may be included in the message. Some or all of the data included in the electronic ID authentication request message can be encrypted using an electronic ID access control computer public key, an electronic ID private key, and/or a session key. The electronic ID authentication request message may also include a certificate and/or public key associated with the electronic ID. In some embodiments, the electronic ID authentication request message may be generated by an access device at which the electronic ID is being presented. The electronic ID authentication request message may also include information provided by the access device, such as a location, a time, biometric data collected from a user at the time when the electronic ID is presented, and/or any other information that may be utilized in determining whether to authenticate an electronic ID. Additionally, in some embodiments, the electronic ID authentication request message may include information for verifying the authenticity of the access device, such as a digital signature generated by the access device and/or a certificate issued to the access device. [0044] An “electronic ID authentication response message” may be reply to an electronic ID authentication request message. In some embodiments, an electronic ID authentication response message may be an electronic message generated by an electronic ID access control computer to reply to an electronic ID authentication request message. The electronic ID authentication response message may include some or all of the information included in the electronic ID authentication request message. In some embodiments, the electronic ID authentication response message may include a confirmation data element, which may be a data element that indicates successful authentication of the electronic ID. The confirmation data element, which is also referred to as a “fingerprint,” may serve as proof of authentication. In some embodiments, the confirmation data element can be a hash value generated based on at least some of the other data elements included in the electronic ID authentication response message, the electronic ID authentication 12 77627443V.1 PATENT Attorney Docket No.: 079900-1395618 Client Reference No.: 7160WO01 request message, or associated with the electronic ID. For example, the confirmation data element can be a hash value generated based on the identification number of the electronic ID, the certificate of the electronic ID, and/or any other suitable electronic ID data. In some embodiments, the confirmation data element can be a digital signature generated based on a private key associated with the electronic ID access control computer, the hash value, and/or some of the other data elements (e.g., a timestamp, an identification number) included in the electronic ID authentication response message or the electronic ID authentication request message. Some or all of the data included in the electronic ID authentication response message can be encrypted using an electronic ID access control computer private key, an access device public key, and/or a session key. [0045] An “authorization request message” may be an electronic message that requests authorization for a transaction. In some embodiments, it is sent to a payment processing network and/or an issuer of a payment account to request authorization for a payment transaction. An authorization request message according to some embodiments may comply with ISO 8583, which is a standard for systems that exchange electronic transaction information associated with a payment made by a consumer using a payment device or a payment account. An authorization request message may also comprise additional data elements corresponding to “identification information” including, for example, a service code, a CVV (card verification value), a dCVV (dynamic card verification value), an expiration date, etc. An authorization request message may also comprise “transaction data,” such as any information associated with a current transaction (e.g., the transaction amount, merchant identifier, merchant location, etc.), as well as any other information that may be utilized in determining whether to identify and/or authorize a payment transaction. [0046] An “authorization response message” may be reply to an authorization request message. In some embodiments, an authorization response message may be an electronic message reply to an authorization request message generated by an issuing financial institution (i.e., issuer) or a payment processing network. An authorization response message according to some embodiments may comply with ISO 8583, which is a standard for systems that exchange electronic transaction 13 77627443V.1 PATENT Attorney Docket No.: 079900-1395618 Client Reference No.: 7160WO01 information associated with a payment made by a consumer using a payment device or a payment account. The authorization response message may include an authorization code, which may be a code that an account issuing bank returns in response to an authorization request message in an electronic message (either directly or through the payment processing network) to a merchant's access device (e.g., point of sale terminal) that indicates approval of the transaction. The code may serve as proof of authorization. As noted above, in some embodiments, a payment processing network may generate and/or forward the authorization response message to the merchant. [0047] An “authorization computer” may include any system involved in authorization of a transaction. The authorization computer may determine whether a transaction can be authorized and may generate an authorization response message including an authorization status (also may be known as an authorization decision). In some embodiments, an authorization computer may be a payment account issuer computer. In some cases, the authorization computer may store contact information of one or more users. In other embodiments, the authorization computer may authorize non-financial transactions involving a user. For example, the authorization computer may make an authorization decision regarding whether the user can access a certain resource. In some cases, the authorization computer may be a content provider server computer associated with a content providing entity, which manages one or more resources that may be accessed by the user. The authorization computer may be known as an authorizing entity computer. The authorization computer may include an “access control server” that may be configured to authenticate a user. [0048] A “network processing computer” or a “processing computer” may include a server computer used for interaction processing. In some embodiments, the network processing computer may be coupled to a database and may include any hardware, software, other logic, or combination of the preceding for servicing the requests from one or more client computers or user devices. The network processing 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 or user devices. In some 14 77627443V.1 PATENT Attorney Docket No.: 079900-1395618 Client Reference No.: 7160WO01 embodiments, the network processing computer may operate multiple server computers. In such embodiments, each server computer may be configured to process an interaction for a given region or handles transactions of a specific type based on interaction data. [0049] The network processing computer may include data processing subsystems, networks, and operations used to support and deliver authorization services, exception file services, and clearing and settlement services. An exemplary network processing computer may include VisaNet™. Networks that include VisaNet™ are able to process credit card transactions, debit card transactions, and other types of commercial transactions. VisaNet™, in particular, includes an integrated payments system (Integrated Payments system) which processes authorization requests and a Base II system, which performs clearing and settlement services. The network processing computer may use any suitable wired or wireless network including the Internet. [0050] The network processing computer may process transaction-related messages (e.g., authorization request messages and authorization response messages) and determine the appropriate destination computer (e.g., issuer computer/authorizing entity computer) for the interaction-related messages. In some embodiments, the network processing computer may authorize interactions on behalf of an issuer. The network processing computer may also handle and/or facilitate the clearing and settlement of financial transactions. [0051] An “interaction request message” may be an electronic message that indicates that the user has initiated an interaction with a resource provider. An interaction request message may include transaction data associated with the interaction. [0052] An “interaction response message” may be an electronic message that is used to respond to an interaction request message. In some embodiments, an interaction response message may indicate that the interaction associated with an interaction request message was successful or unsuccessful. [0053] 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 15 77627443V.1 PATENT Attorney Docket No.: 079900-1395618 Client Reference No.: 7160WO01 access devices include an energy supply terminal (e.g., an electric charger at a charging station), gasoline pumps, 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. [0054] A “processor” may include a device that processes something. In some embodiments, a processor can include 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). [0055] 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. [0056] 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 16 77627443V.1 PATENT Attorney Docket No.: 079900-1395618 Client Reference No.: 7160WO01 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. [0057] Embodiments provide for a system and method that incorporate an electronic ID into a transaction system. For example, a token service computer can associate a user’s electronic ID with a user’s transaction account. As a result, two user accounts (e.g., identity and payment) which are typically separate can become associated. [0058] In some embodiments, an electronic ID can be presented to an access device, and the access device can communicate with an identity-authenticating entity to authenticate the electronic ID. When successfully authenticated, the access device can receive proof of the authentication from the identity-authenticating entity. The access device can then submit the proof of authentication to a token service computer, which can retrieve a token associated with the electronic ID. The token service computer can provide the token to the access device, and the access device can then submit the token for a transaction. Accordingly, an electronic ID authentication system, which is typically separate from a transaction system, can be tied to token transaction system such that an electronic ID can become usable for transactions. [0059] For the electronic ID to be usable for a transaction, the access device may use three different consecutive requests to communicate with three different entities. A first request can be an eID authentication request message that the access device transmits to an eID access control computer to authenticate the user’s electronic ID. A second request can be a token request message that the access device transmits to a token service computer to retrieve a token associated with the electronic ID. A third request can be an authorization request message that the access device transmits to a processing computer to process the transaction based on the token (which identifies an associated transaction account). Thus, the electronic ID can be converted into a token which is usable within transaction systems. This can be accomplished without requiring that the identification system and transaction system be modified to directly interact or cooperate, such that the 17 77627443V.1 PATENT Attorney Docket No.: 079900-1395618 Client Reference No.: 7160WO01 identification system and transaction systems can maintain their separation and current operations. [0060] According to some embodiments, electronic ID information that may be considered sensitive may be protected. For example, the process for authenticating an electronic ID can be protected through encryption and other security protocols. Further, the electronic ID information may not be shared, or may only be shared in a limited capacity. For example, the eID access control computer may only provide a confirmation data element, such as a verifiable hash value and/or digital signature, to the access device and/or token service computer. As a result, the access device and/or token service computer can be informed that the electronic ID is authentic without exposing identity information. [0061] FIG.1 shows a block diagram of a system 100 for registering an electronic ID for use in a transaction system, in accordance with at least one embodiment. The system 100 comprises a user device 102, a registration device 105, an eID access control computer 110, and a token service computer 120. [0062] The user device 102 can take the form of an electronic identification, the eID access control computer 110 can be configured to authenticate electronic identifications, and the token service computer 120 can be configured to map token data to an electronic ID or associated identity information. The user device 102, eID access control computer 110, and token service computer 120 are each discussed in greater detail below with respect to FIG.2. [0063] The registration device 105 may be any suitable device for interacting with a user device 102 and for communicating with a token service computer 120 and an eID access control computer 110. The registration device 105 may be configured to allow a user to register a user device 102 for usage in a transaction system. For example, the user device 102 may already be configured to serve as proof of identity, but may not be configured to provide credentials for a transaction. The registration device 105 can generate and send a registration request message to the token service computer 120 to associate the user device 102 with a token and/or payment account. 18 77627443V.1 PATENT Attorney Docket No.: 079900-1395618 Client Reference No.: 7160WO01 [0064] The registration device 105 may be the same as or similar to the access device 135 described below with respect to FIGS.2-3. However, the registration device 105 may be located in a different location than the access device 135. As an example, the registration device 105 may take the form of an ATM or other card reader located in a bank. [0065] A method according to embodiments of the invention can also be described with respect to FIG.1. In the method illustrated in FIG.1, electronic ID information may be passed from the user device 102 to the registration device 105 to register the electronic ID for usage in a transaction system. The steps shown in the method may be performed sequentially or in any suitable order in embodiments of the invention. In some embodiments, one or more of the steps may be optional. [0066] A user may wish to utilize a user device 102 in the form of an electronic ID for payment transactions. To initiate the method, a user can interact with a registration device 105 to request that the user device 102 become associated with a payment account. This can include providing information about an existing payment account (e.g., credentials) to any suitable registration device 105 in any suitable location. For example, the user may be able to initiate the method at an ATM, or at any other registration device 105 that is in communication with the eID access control computer 110 and/or the token service computer 120. The user may provide information about any suitable type of payment account, such as a credit line, a checking account, a debit account, a digital wallet, a P2P wallet, or any other suitable funding source, any of which can be pre-existing or can be newly created as a part of the registration request. [0067] In some embodiments, before an association can be created between the user device 102 and the payment account, the user device 102 may first be authenticated. The user may present the user device 102 to the registration device 105 so that the user device 102 and registration device 105 can begin communications. For example, the user can tap or insert the user device 102 at the reader of registration device 105. [0068] At step A, the user device 102 can provide electronic ID information to the registration device 105. Step A can be similar to or the same as step 1 described below with respect to FIG.2. 19 77627443V.1 PATENT Attorney Docket No.: 079900-1395618 Client Reference No.: 7160WO01 [0069] At step B, the registration device 105 can generate and transmit an eID authentication request message to the eID access control computer 110. The eID authentication request message can comprising the electronic ID information received from the user device 102 in step A. Step B can be similar to or the same as step 2 described below with respect to FIG.2. [0070] At step C, the eID access control computer 110 can verify that the electronic ID is authentic. For example, the eID access control computer 110 can decrypt information included in the eID authentication request message, check a database to verify that the electronic ID information is valid, verify a digital signature, and/or verify a certificate associated with the user device 102. Step C can be similar to or the same as step 3 described below with respect to FIG.2. [0071] At step D, the eID access control computer 110 can generate and transmit an eID authentication response message to the registration device 105 indicating that the user device 102 is authentic. The eID authentication response message may include a confirmation data element indicating that the electronic ID was verified by the eID access control computer 110. Step D can be similar to or the same as step 4 described below with respect to FIG.2. [0072] At step E, in response to receiving the eID authentication response message, the registration device 105 can generate and transmit a registration request message to the token service computer 120. The registration request message can include an identification number, user data, a confirmation data element indicating that the electronic ID was verified by the eID access control computer 110, and/or any other suitable identity information. Additionally, the registration request message can include information, such as credentials, indicating an account to be associated with the electronic ID. In some embodiments, sensitive identification information, such as the identification number, are not provided to the token service computer 120, and the token service computer 120 instead relies on encrypted or obscured information related to the electronic ID, such as the confirmation data element. [0073] At step F, the token service computer 120 can validate the registration request message. For example, the token service computer 120 can verify a digital signature or other confirmation data element using a public key associated with the 20 77627443V.1 PATENT Attorney Docket No.: 079900-1395618 Client Reference No.: 7160WO01 eID access control computer 110 to confirm that the eID access control computer 110 authenticated the electronic ID. The public key associated with the eID access control computer 110 can be included (e.g., in the form of a digital certificate issued by a certificate authority) in the registration request message or retrieved from a public database. Additionally, the token service computer 120 can check a timestamp included in the token request message to verify that the eID access control computer 110 validated the electronic ID recently, within a predetermined time threshold (e.g., 10 seconds, 30 seconds, 1 minute, 5 minutes, 10 minutes, etc.). [0074] The token service computer 120 can also identify a payment account associated with the credentials received in the registration request message. This can include obtaining and/or generating a token, token cryptogram, and/or any other suitable token data for the payment account. [0075] The token service computer 120 can then create an association between the electronic ID, the token, and/or the payment account. For example, the token service computer 120 can create a record or account that includes the token associated with the payment account, the credentials associated with the payment account, and/or certain identity information associated with the electronic ID. The identity information can include the identification number, the user data, the confirmation data element indicating that the electronic ID was verified by the eID access control computer 110, and/or any other suitable identity information. Some or all of the identity information can be received and/or stored in an encrypted form. In some embodiments, the confirmation data element may be the only identity information stored in order to minimize distribution and exposure of other identity information. [0076] At step G, the token service computer 120 may then generate and transmit a registration response message to the registration device 105 indicating that the electronic ID is now associated with the payment account. As a result, the electronic ID can now be presented to an access device 135 for a future interaction, and the electronic ID can be converted into a token by the token service computer 120 as part of the interaction. An example future interaction is described below with respect to FIG.2. 21 77627443V.1 PATENT Attorney Docket No.: 079900-1395618 Client Reference No.: 7160WO01 [0077] Embodiments allow the method to be repeated so that the electronic ID can be registered for association with a different payment account at any suitable time in the future. In further embodiments, a user may be able to access their account (e.g., via webpage or mobile application) at the token service computer to dynamically switch which payment account is currently associated with their electronic ID. [0078] FIG.2 shows a system 200 according to embodiments of the disclosure. The system 200 comprises a user device 102, an access device 135, an eID access control computer 110, a token service computer 120, a resource provider computer 140, a transport computer 141, a processing computer 142, and an authorizing entity computer 143. [0079] The user device 102 can be in operative communication with the access device 135. The access device 135 can be in operative communication with the eID access control computer 110, the token service computer 120, and the resource provider computer 140. The resource provider computer 140 can be in operative communication with the transport computer 141. The transport computer 141 can be in operative communication with the network processing computer 142. The network processing computer can be in operative communication with the authorizing entity computer 143 and the token service computer 120. [0080] For simplicity of illustration, a certain number of components are shown in FIG.2. It is understood, however, that embodiments of the invention may include more than one of each component. In addition, some embodiments of the invention may include fewer than or greater than all of the components shown in FIG.2. [0081] Messages between the devices in the system 200 in FIG.2 can be transmitted using a secure communications protocols such as, but not limited to Secure Hypertext Transfer Protocol (HTTPS), SSL, ISO (e.g., ISO 8583) and/or the like. The communications network include any one and/or the combination of the following: a direct interconnection; the Internet; a Local Area Network (LAN); a Metropolitan Area Network (MAN); an Operating Missions as Nodes on the Internet (OMNI); 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), I-mode, and/or the like); and/or the like. The communications 22 77627443V.1 PATENT Attorney Docket No.: 079900-1395618 Client Reference No.: 7160WO01 network can use any suitable communications protocol to generate one or more secure communication channels. A communications channel may, in some instances, comprise a secure communication channel, which may be established in any known manner, such as through the use of mutual authentication and a session key, and establishment of a Secure Socket Layer (SSL) session. [0082] A user can use the user device 102 to initiate interactions (e.g., transactions) with the access device 135. For example, a user can present the user device 102 to the access device 135 to conduct an interaction, such as an identity interaction. Upon being inserted, tapped, or otherwise brought near to or into physical contact with the access device 135, the user device 102 can communicate with the access device 135 to conduct the interaction. For example, the user device 102 can communicate with the access device 135 through physical contacts, or through contactless short-range communications (e.g., NFC, RF, Bluetooth, etc.). [0083] In some embodiments, the user device 102 can take the form of an electronic identification. An electronic ID can include identity information that can be used to authenticate the identity of a user to which the electronic ID is assigned. An electronic ID can be a physical item with identity information that is visually displayed and/or digitally encoded information for both online and offline identification of individuals or organizations. [0084] A user device 102 in the form of an electronic ID can include a card (e.g., a plastic or metal substrate), a booklet, or any other suitable physical object. The electronic ID can include printed, embossed, or otherwise visible identity information. The identity information can be related to the user’s identity and/or a user identity account. For example, the identity information can include an identification number (e.g., a passport number, license number, or badge number), name, address, age, date of birth, place of birth, weight, eye color, nationality, ethnicity, expiration date, issue date, a photograph, and/or and other suitable personal details. Examples of an electronic ID include an electronic passport (“ePassport”) and an electronic identification card (e.g., e-Driving license, smart card). [0085] Additionally, a user device 102 in the form of an electronic ID can also include digitally encoded information. For example, a contact element, contactless 23 77627443V.1 PATENT Attorney Docket No.: 079900-1395618 Client Reference No.: 7160WO01 element (e.g., an RFID chip) and/or a magnetic stripe for interfacing with the access device may be present on, or embedded within, a substrate or page of the user device 102. In some embodiments, the user device 102 may comprise any other suitable attached or embedded microprocessors, antennas, and/or memory chips with user data stored in them. The memory chips may contain digital versions of identity information, such as some or all of the visible identity information. Additionally, the memory chips can contain a digital certificate, one or more encryption keys, a dynamic chip identifier (e.g., that changes for each interaction and/or message), one or more biometric templates (e.g., fingerprint templates, facial recognition templates, etc.), one or more biometric images, and/or or other data for biometric verification. Biometric verification files can be formatted to comply with the specifications in the International Civil Aviation Organization's (ICAO) Doc 9303. [0086] In some embodiments, the user device 102 can include one or more portable computers, mobile devices, cellular phones, wearable devices (e.g., watches, glasses, lenses, clothing, etc.), personal digital assistants (PDAs), Internet of Things (IoT) devices, and/or the like. Such a user device 102 can include an electronic identification in the form of one or more software modules and/or secure hardware elements (which can be referred to as a digital identification) installed on the user device 102. [0087] In some embodiments, the user device 102 may not include payment credentials or otherwise be configured for typical payment transactions. Instead, the user device 102 can be configured solely for identity interactions and identity authentication. Even without payment credentials or typical payment transaction configurations, embodiments provide methods and systems that enable identity interactions to be converted into or otherwise leveraged for payment transactions. [0088] The user device 102 may be configured to interact only with certain authorized devices. For example, the user device 102 can authenticate the access device 135 to ensure that the access device 135 is configured to receive and process identity information, and to communicate according to certain predefined security protocols (which are discussed in more detail below). [0089] An access device 135 may be any suitable device for interacting with a user device 102 and for communicating with a resource provider computer 140, a 24 77627443V.1 PATENT Attorney Docket No.: 079900-1395618 Client Reference No.: 7160WO01 token service computer 120, and an eID access control computer 110. An access device 135 can be in any suitable location such as at the same location as a merchant, and an access device 135 may be in any suitable form. Some examples of access devices include POS devices, 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, Websites, and the like. Typically, an access device 135 may use any suitable contact or contactless mode of operation to send or receive data from a user device 102. [0090] An example of the access device 135, according to some embodiments of the invention, is shown in FIG.3. The access device 135 may comprise a processor 206 operatively coupled to a memory 208 and a data storage 202 (e.g., one or more memory chips, etc.), a user interface 204 including input elements (e.g., buttons or the like) and output elements (e.g., a display, a speaker, etc.), one or more readers 203 (e.g., a contact chip reader, a contactless reader, a magnetic stripe reader, a biometric reader, etc.), and a network interface 205. A housing may house one or more of these components. The processor 206 can be implemented as one or more integrated circuits (e.g., one or more single core or multicore microprocessors and/or microcontrollers). The processor 206 can execute a variety of programs in response to program code or computer-readable code stored in the memory 208 and data storage 202, and can maintain multiple concurrently executing programs or processes. [0091] Memory 208 can be implemented using any combination of any number of non-volatile memories (e.g., flash memory) and volatile memories (e.g., DRAM, SRAM), or any other non-transitory storage medium, or a combination thereof media. Memory 208 may store a number of software components or modules including an electronic identification control module 208A, a token module 208B, and a transaction processing module 208C. Each of the software components can be executed by processor 206. [0092] In some embodiments, the memory 208 can include a non-transitory computer readable medium comprising code, executable by the processor for implementing a method comprising: receiving, by an access device comprising an 25 77627443V.1 PATENT Attorney Docket No.: 079900-1395618 Client Reference No.: 7160WO01 electronic ID control module and a transaction processing module, a communication comprising electronic ID information from a user device in a transaction, transmitting, by the access device, an electronic ID authentication request message to an electronic ID access control computer, receiving, by the access device, an electronic ID authentication response message from the electronic ID access control computer, in response to receiving the electronic ID authentication response message, transmitting, by the access device, a token request message to a token service computer, receiving, by the access device, a token response message comprising a token from the token service computer, generating, by the access device, an authorization request message comprising the token and a value, and transmitting, by the access device, the authorization request message comprising the token to a processing computer, which processes the transaction using the using the token. [0093] In some embodiments, the memory 208 can include a non-transitory computer readable medium comprising code, executable by the processor for implementing a method comprising: receiving, by an access device, a communication comprising electronic ID information from a user device in a transaction; transmitting, by the access device, an electronic ID authentication request message to an electronic ID access control computer; receiving, by the access device, an electronic ID authentication response message from the electronic ID access control computer; in response to receiving the electronic ID authentication response message, transmitting, by the access device, a registration request message to a token service computer, which stores an association between a token and the user device. [0094] The electronic identification control module 208A may comprise code that causes the processor 206 to authenticate an electronic identification. For example, the electronic identification control module 208A may contain logic that causes the processor 206 to communicate with a user device 102 to obtain identity information. Additionally, the electronic identification control module 208A can, in conjunction with the processor 206, communicate with an eID access control computer 110 to verify that the identity information received from the user device 102 is authentic. For example, electronic identification control module 208A can, in conjunction with the processor 206, transmit an eID authentication request message 26 77627443V.1 PATENT Attorney Docket No.: 079900-1395618 Client Reference No.: 7160WO01 to the eID access control computer 110. An eID authentication request message can include any suitable information for authenticating an electronic ID, such as an identification number, user data (e.g., name, age, address, date of birth), a cryptogram and/or digital signature, dynamic data elements (e.g., a timestamp, challenge value, or counter), and/or any other suitable information received from a user device 102. Some or all of the data included in the eID authentication request message can be encrypted. [0095] The electronic identification control module 208A may be configured to use any suitable security protocols and security measures for communications with the user device 102 and/or eID access control computer 110, such as basic access control (BAC), passive authentication (PA), Active Authentication (AA), Extended Access Control (EAC), Supplemental Access Control (SAC), ISO/IEC 14443 for proximity cards, and/or ISO/IEC 18092 for NFC-enabled devices. [0096] BAC protects the communication channel between the user device 102 and the access device 135 by encrypting transmitted information using an encryption key that the access device 135 generates based on information from the derived from a machine-readable zone of the user device 102, such as a date of birth, a date of expiry, and a document number. [0097] PA can identify modification of user device 102 data. The user device 102 can store a Document Security Object (SOD) file that stores hash values of all files stored in the user device 102 (e.g., biometric verification data, etc.) and a digital signature of these hashes. The digital signature is generated using a document signing key which itself is signed by a country signing key. If a file in the user device 102 (e.g., biometric verification data) is changed, this can be detected since the hash value will become incorrect. [0098] AA can prevent cloning of user device chips by providing the user device 102 with a private key that cannot be read or copied. A challenge can be issued to the user device 102 by the access device 135, and the user device 102 can generate a response by creating a digitally signature based on the challenge with the private key. The access device 135 can then validate the response using a corresponding public key. 27 77627443V.1 PATENT Attorney Docket No.: 079900-1395618 Client Reference No.: 7160WO01 [0099] EAC provides functionality to check the authenticity of both the user device 102 (chip authentication) and the access device 135 (terminal authentication). A chip-specific key pair is used for chip authentication such that only the correct user device 102 with the correct key pair can prove that it is the correct device (e.g., based on digital signatures and/or certificates). Terminal authentication (TA) is used to determine whether the access device 135 is allowed to read sensitive data from the user device 102. The access device 135 can be provided with a card verifiable certificate (CVC). The user device 102 can authenticate the access device 135 by, for example, verifying a digital signature generated by the access device 135 with a public key included in the certificate. Once the user device 102 verifies the access device 135, the user device 102 may allow the access device 135 to sensitive data such as biometric verification data from the user device 102. The access device’s certificate may be valid only for a predefined time period, such as 1 day, 1 month, or an amount of time between 1 day and 1 month). The certificate may be provided by a document verifier (DV), which may also have its own certificate granted from the country verification certificate authority (CVCA). [0100] Supplemental Access Control specifies the Password Authenticated Connection Establishment (PACE) protocol, where a user provides the access device 135 with user-known information such as a PIN and/or some printed data from the user device 102. If the information matches corresponding information stored at the user device 102, the access device 135 and/or user device 102 can proceed with the interaction. [0101] In some embodiments, the electronic identification control module 208A may be configured to keep data received from the user device 102 secure. For example, sensitive information (e.g., identification number, name, address, etc.) may not be provided to other modules (e.g., the token module 208B and/or transaction processing module 208C), and/or may not be provided to other computers or entities (e.g., the resource provider computer 140 and/or token service computer 120). [0102] The token module 208B may comprise code that causes the processor 206 to request and receive tokens. For example, the token module 208B may contain logic that causes the processor 206 to send a token request message to a 28 77627443V.1 PATENT Attorney Docket No.: 079900-1395618 Client Reference No.: 7160WO01 token service computer 120. The token request message may include a confirmation data element received from the eID access control computer 110 indicating that the user device 102 is authenticated. The token request message may also include identity information (which may be encrypted) received from the user device 102, resource provider identity information, and any other suitable information. [0103] The transaction processing module 208C may comprise code that causes the processor 206 to process transactions. For example, the transaction processing module 208C may contain logic that causes the processor 206 to initiate a transaction authorization process, and to finalize a transaction so that goods and/or services can be released. A transaction authorization process can be initiated by generating a sending authorization request message to the resource provider computer 140. The authorization request message can include a token and any other suitable information. [0104] In some embodiments, the access device 135 may be configured to communicate with at least three separate remote server computers. For example, the access device 135 can send an eID authentication request message to the eID access control computer 110 (which can be referred to as a first request sent to a first computer) to authenticate the user device 102 and obtain a confirmation data element, the access device 135 can send a token request message to the token service computer 120 (which can be referred to as a second request sent to a second computer) to obtain a token, and/or the access device 135 can send an authorization request message to a processing computer 142 (which can be referred to as a third request sent to a third computer) via a resource provider computer 140 and/or a transport computer 141 to obtain transaction authorization. [0105] The data storage 202 may store any suitable information related to electronic identification authentication, token systems, and/or transaction systems. For example, in some embodiments, the data storage 202 may store one or more encryption keys and/or certificates issued to the access device 135 for communicating with the eID access control computer 110 or otherwise participating in identity transactions. 29 77627443V.1 PATENT Attorney Docket No.: 079900-1395618 Client Reference No.: 7160WO01 [0106] In some embodiments, certain functionality and/or software modules of the access device 135 may alternatively be embodied at the resource provider computer 140. For example, the token module 208B and/or transaction processing module 208C may be installed at the resource provider computer 140, such that the resource provider computer 140 performs the tasks of obtaining tokens (e.g., generating and transmitting token request messages) and/or obtaining authorization (e.g., generating and transmitting authorization request messages) after receiving any suitable information (e.g., a confirmation data element and/or token) from the access device 135. [0107] The network interface 205 may include an interface that can allow the access device 135 to communicate with external computers. Some examples of the network interface 205 may include a modem, a physical network interface (such as an Ethernet card or other Network Interface Card (NIC)), a virtual network interface, a communications port, a Personal Computer Memory Card International Association (PCMCIA) slot and card, or the like. The wireless protocols enabled by the network interface 205 may include Wi-Fi^TM. Data transferred via the network interface 205 may be in the form of signals which may be electrical, electromagnetic, optical, or any other signal capable of being received by the external communications interface (collectively referred to as “electronic signals” or “electronic messages”). These electronic messages that may comprise data or instructions may be provided between the network interface 205 and other devices via a communications path or channel. As noted above, any suitable communication path or channel may be used such as, for instance, a wire or cable, fiber optics, a telephone line, a cellular link, a radio frequency (RF) link, a WAN or LAN network, the Internet, or any other suitable medium. [0108] Referring back to FIG.2, the eID access control computer 110 can be any suitable device for authenticating identities. The eID access control computer 110 can include a server computer operated by an identity authenticating entity, which may be an entity that authenticates an identity. An example of an authenticating entity may be a government entity, business entity, or other authority that provides and/or manages identification documents for individuals. The eID access control computer 110 may include data processing subsystems, networks, 30 77627443V.1 PATENT Attorney Docket No.: 079900-1395618 Client Reference No.: 7160WO01 and operations used to support and deliver identity authentication services. For example, the eID access control computer 110 may comprise a server coupled to a network interface (e.g., by an external communication interface), and databases of information. The eID access control computer 110 may use any suitable wired or wireless network, including the Internet. [0109] The eID access control computer 110 can store any suitable information about one or more users, electronic identifications, and/or identity accounts. The eID access control computer 110 can be configured to validate identity information received in an eID authentication request message by comparing with identity information stored in a database. The eID access control computer 110 may also be configured to verify the authenticity of requesting user devices and/or access devices (e.g., by validating corresponding digital signatures). The eID access control computer 110 may be configured to generate an eID authentication response message indicating whether an identity was successfully authenticated, encrypt some or all information included in the authentication response message, and/or generate a confirmation data element for the authentication response message. For example, the confirmation data element can be a hash value generated based on the identification number of the electronic ID, the certificate of the electronic ID, and/or any other suitable electronic ID data. Additionally or alternatively, the confirmation data element can include a digital signature generated using an eID access control computer private key. [0110] In some embodiments, the eID access control computer 110 may function as a Single Point of Contact (SPOC) that is configured to verify electronic IDs for a specific region or group. Additionally, the eID access control computer 110 be a Document Verifying Certification Authority that issues certificates and/or keys to the access device 135 and/or the user device 102. In some embodiments, the eID access control computer 110 can distribute software for participating in an identity authentication network to the access device 135, such as the electronic identification control module 208A. [0111] The token service computer 120 can include a computer programmed to facilitate requesting, determining (e.g., generating) and/or issuing token data, as well as maintaining an established mapping of token data to identity information 31 77627443V.1 PATENT Attorney Docket No.: 079900-1395618 Client Reference No.: 7160WO01 (e.g., confirmation data element, identification number, etc.) and/or credentials (e.g., primary account numbers) in a repository (e.g., token vault). The token service computer 120 may include or be in communication with a token vault where the generated tokens are stored. The token service computer 120 may support token processing of interactions submitted using tokens by de-tokenizing the tokens to obtain the actual credentials. In some embodiments, a token service computer 120 may include a tokenization computer alone, or in combination with other computers such as a network processing computer 142. [0112] An example of a token service computer 120, according to some embodiments of the invention, is shown in FIG.4. The exemplary token service computer 120 may comprise a processor 304. The processor 304 may be coupled to a network interface 306, a token vault 302, and a memory 308. The memory 308 can comprise a token module 308A, and a communication module 308B. [0113] The token vault 302 can be used to store data and code. For example, the token vault 302 can be a secure database which can store tokens, token cryptograms, credentials, identity data, etc. The token vault 302 may be coupled to the processor 304 internally or externally (e.g., cloud-based data storage), and may comprise any combination of volatile and/or non-volatile memory, such as RAM, DRAM, ROM, flash, or any other suitable memory device. [0114] In some embodiments, the token vault 302 can store information for associating a token with an identity. For example, a confirmation data element indicating that an eID access control computer 110 has authenticated an electronic ID can be stored in association with the token. In some embodiments, other data related to an electronic ID, such as an identification number, name, address, or any other suitable information can be stored in association with a token. Some or all of the stored information related to identity can be protected by encryption, and may or may not be accessible to the token service computer 120 in an unencrypted form. In other embodiments, only the confirmation data element is stored at the token vault 302, and other electronic ID information is not stored or received by the token service computer 120. [0115] The token module 308A can include may comprise code or software, executable by the processor 304, for processing tokens. The token module 308A, in 32 77627443V.1 PATENT Attorney Docket No.: 079900-1395618 Client Reference No.: 7160WO01 conjunction with the processor 304, can generate or obtain token data that corresponds to identity information and/or credentials of users. The token module 308A, in conjunction with the processor 304, can generate the token data in any suitable manner. The token module 308A, in conjunction with the processor 304, can generate a token that appears to be a string of random characters and does not relate to tokens created previously or subsequently. The token module 308A, in conjunction with the processor 304, can generate the token data based on random values, keys, user data, user device data, etc. [0116] For example, the token module 308A, in conjunction with the processor 304, can receive a token request message from an access device. Upon receipt of the token request message, the token module 308A, in conjunction with the processor 304, can verify that the identity information and/or confirmation data element included in the token request message is valid and/or associated with a certain account. For example, the token module 308A, in conjunction with the processor 304, can determine whether or not a set of identity information and/or a confirmation data element stored in a secure token database matches the received identity information and/or confirmation data element. [0117] The communication module 308B include may comprise code or software, executable by the processor 304, for communicating with other devices. The communication module 308B, in conjunction with the processor 304, can generate messages, receive messages, and parse messages. The communication module 308B, in conjunction with the processor 304, can receive token request messages, credential request messages, etc. The communication module 308B, in conjunction with the processor 304, can generate and transmit token response messages, credential request messages, etc. [0118] For example, the communication module 308B, in conjunction with the processor 304, can receive a token request message from a token requestor computer (e.g., an access device). The token request message may include at least a confirmation data element indicating that an eID access control computer 110 has verified that an indicated user’s identity has been authenticated. [0119] In some embodiments, the token vault 302 can store token data, identity data, and credential data together as all associated together in an account. 33 77627443V.1 PATENT Attorney Docket No.: 079900-1395618 Client Reference No.: 7160WO01 A token request message including identity data can cause the token service computer 120 to identify the account and retrieve the token data. A credential request message including the token data can cause the token service computer 120 to identify the account and retrieve the credential data. [0120] The network interface 306 may be similar to the network interface 205 and the descriptions thereof are incorporated herein and need not be repeated here. [0121] Referring back to FIG.2, the resource provider computer 140 can include any suitable computational apparatus operated by a resource provider (e.g., a merchant). In some embodiments, the resource provider computer 140 may be configured to send data to a network processing computer 142 via a transport computer 141 as part of a payment verification and/or authentication process for a transaction between the user (e.g., consumer) and the resource provider. The resource provider computer 140 may also be configured to generate authorization request messages for transactions between the resource provider and the user, and route the authorization request messages to an authorizing entity computer 143 for transaction processing. In some embodiments, the resource provider computer 140 may include one or more server computers that may host one or more websites associated with the resource provider (e.g., a merchant). [0122] The transport computer 141 can include a server computer. The transport computer 141 may be associated with an acquirer, which may be an 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. [0123] The processing computer 142 may be disposed between the transport computer 141 and the authorizing entity computer 143. The processing computer 142 may include data processing subsystems, networks, and operations used to support and deliver authorization services, exception file services, and clearing and settlement services. For example, the processing computer 142 may comprise a server coupled to a network interface (e.g., by an external communication interface), and databases of information. The processing computer 142 may be representative of a transaction processing network. An exemplary transaction processing network may include VisaNet™. Transaction processing networks such as VisaNet™ are 34 77627443V.1 PATENT Attorney Docket No.: 079900-1395618 Client Reference No.: 7160WO01 able to process credit card transactions, debit card transactions, and other types of commercial transactions. VisaNet™, in particular, includes a VIP system (Visa Integrated Payments system) which processes authorization requests and a Base II system which performs clearing and settlement services. The processing computer 142 may use any suitable wired or wireless network, including the Internet. [0124] The authorizing entity computer 143 can include a server computer operated by an authorizing entity. An authorizing entity may be an entity that authorizes a request. An example of an authorizing entity may be an issuer, which may typically refer to a business entity (e.g., a bank) that maintains an account for a user. An issuer may also issue and manage an account associated with a user device. [0125] The processing computer 142, the transport computer 141, and the authorizing entity computer 143 may operate suitable routing tables to route authorization request messages and/or authorization response messages using credentials, token data, merchant identifiers, and/or other account identifiers. [0126] A method according to embodiments of the invention can also be described with respect to FIG.2. In the method illustrated in FIG.2, electronic ID information may be passed from the user device 102 to the access device 135 to initiate a payment transaction process. The method in FIG.2 advantageously allows electronic IDs to be used for payment transactions, even though such devices may not contain payment account information. The steps shown in the method may be performed sequentially or in any suitable order in embodiments of the invention. In some embodiments, one or more of the steps may be optional. [0127] A user may wish to purchase a good or service from the resource provider. To initiate the method, a user can present the user device 102 to the access device 135 so that the user device 102 and access device 135 can begin communications. For example, the user can tap or insert the user device 102 at the reader of the access device 135. [0128] At step 1, the user device 102 can provide electronic ID information to the access device 135 for an identity interaction. For example, the user device 102 can provide an identification number (e.g., license number, passport number), user 35 77627443V.1 PATENT Attorney Docket No.: 079900-1395618 Client Reference No.: 7160WO01 data (e.g., name, age, address, date of birth), and/or any other suitable information encoded on the user device 102. The user device 102 may also provide a cryptogram and/or a digital signature, which may be generated for this interaction, and which may be generated using dynamic input data such as a counter, timestamp, and/or challenge value (e.g., a nonce) received from the access device 135. Accordingly, an access device 135 comprising an electronic ID control module and a transaction processing module can receive a communication comprising electronic ID information from a user device in a transaction. [0129] In some embodiments, some or all of the electronic ID information can be provided to the access device 135 in an encrypted form (e.g., encrypted with a user device private key). Accordingly, the access device 135 may not have access to sensitive unencrypted electronic ID information. [0130] In some embodiments, the electronic ID information can be provided to the access device 135 for the identity interaction through a series of one or more communications according to any suitable communication protocol, such as ISO/IEC 7816. For example, the one or more communications can include Application Protocol Data Unit (ADPU) messages. The one or more communications can include communications to establish a secure communication channel, communications for the user device 102 and the access device 135 to verify the authenticity of the other device (e.g., mutual authentication), and/or exchanging of any suitable information between the user device 102 and the access device 135. In some embodiments, the user device 102 and the access device 135 can mutually authenticate using corresponding private keys and certificates issued by the eID access control computer 110 (e.g., or any other suitable certificate authority). Communications between the user device 102 and the access device 135 can be encrypted and otherwise protected through any suitable secure communication protocol, such as Basic Access Control (BAC), Passive Authentication (PA), Active Authentication (AA), Extended Access Control (EAC), and Supplemental Access Control (SAC). [0131] During the initial communications between the user device 102 and access device 135, the user device 102 may provide an application identifier. The application identifier can indicate that the user device 102 is providing electronic ID information for authentication (e.g., an identity interaction). For example, the 36 77627443V.1 PATENT Attorney Docket No.: 079900-1395618 Client Reference No.: 7160WO01 application identifier ‘A0000002471001' can be used to indicate a electronic Machine Readable Travel Document application, the application identifier ‘A00000 0247 2001' can be used to indicate a travel records application, the application identifier ‘A0000002472002’ can be used to indicate a visa records application, the application identifier ‘A0000002472003’ can be used to indicate a biometrics application, and the application identifier E80704007F00070302 can be used to indicate a German electronic ID application. The access device 135 can determine that the application identifier is associated with an electronic ID application. In response to an application identifier associated with an electronic ID, the access device 135 may determine to utilize an electronic identification control module to process communications with the user device 102. [0132] At step 2, the access device 135 can (e.g., via the electronic identification control module) communicate with the eID access control computer 110 to verify that the electronic ID information received from the user device 102 is authentic. The access device 135 can generate and transmit an eID authentication request message to the eID access control computer 110. The eID authentication request message (also referred to as a “first request”) can comprise the identification number, user data (e.g., name, age, address, date of birth), a cryptogram and/or digital signature, dynamic data elements (e.g., a timestamp, challenge value, or counter), and/or any other suitable information received from the user device 102. Some or all of the data included in the eID authentication request message can be encrypted. [0133] At step 3, the eID access control computer 110 can verify that the electronic ID is authentic. The eID access control computer 110 can determine whether the electronic ID is authentic based on the received eID authentication request message and any other suitable data known to the eID access control computer 110. For example, the eID access control computer 110 can decrypt information included in the eID authentication request message such as the encrypted identification number and/or user data (e.g., using on a private key associated with the eID access control computer 110, or a session key established between the eID access control computer 110 and the user device 102). The eID access control computer 110 can also check a database to verify that the 37 77627443V.1 PATENT Attorney Docket No.: 079900-1395618 Client Reference No.: 7160WO01 identification number is valid, confirm that any other user data included in the eID authentication request message matches database records, validate a cryptogram, and/or verify a digital signature. Further, access control computer 110 can user public key infrastructure to verify a certificate associated with the user device 102, which may be included in the eID authentication request message. For example, the access control computer 110 can verify a digital signature included in the certificate. In some embodiments, the eID access control computer 110 can also perform one or more communications to mutually authenticate with the access device 135 (e.g., by exchanging and verifying digital signatures). [0134] At step 4, the eID access control computer 110 can generate and transmit an eID authentication response message to the access device 135. The eID authentication response message can comprise the indication that the electronic ID is authentic and/or that the user is authorized to access restricted information or services based on the valid electronic ID. The eID authentication response message can further include the identification number, user data (e.g., name, age, address, date of birth), a timestamp, a random value, and/or any other suitable information, some or all of which may be encrypted. [0135] In some embodiments, the eID access control computer 110 can generate a confirmation data element, which may be a data element that indicates successful authentication of the electronic ID. In some embodiments, the confirmation data element can be a hash value generated based on some or all of the information included in the eID authentication response message or associated with the user device 102. For example, the confirmation data element can be a hash value generated based on the identification number of the user device 102, the certificate of the user device 102, and/or any other suitable user device data. Additionally or alternatively, the confirmation data element can include a digital signature generated based on a private key associated with the eID access control computer 110, the hash value, and/or some or all of the information included in the eID authentication response message (e.g., a timestamp, an identification number). The confirmation data element is also referred to as a “fingerprint.” [0136] The access device 135 can verify the eID authentication response message to confirm that the eID access control computer 110 authenticated the 38 77627443V.1 PATENT Attorney Docket No.: 079900-1395618 Client Reference No.: 7160WO01 electronic ID. For example, the access device 135 (e.g., via the electronic identification control module) can verify the confirmation data element (e.g., the hash value and/or digital signature) using a public key associated with the eID access control computer 110. [0137] In some embodiments, the electronic ID information and/or the confirmation data element may not be compatible with, formatted for, configured for, or otherwise processable by a transaction network. For example, the confirmation data element may not be formatted for being included in an authorization request message. Further, the authorizing entity computer 143 may not have any information about the confirmation data element, such that the authorizing entity computer 143 may not be able to identify an account based on the confirmation data element. [0138] Accordingly, to complete a transaction, the confirmation data element may be converted into information that is processable by a transaction network, such as a payment token. Accordingly, after completed authentication of the electronic ID, the electronic identification control module at the access device 135 can determine to provide information about the identity interaction and successful authentication to a token module at the access device 135. For example, the electronic identification control module can provide the confirmation data element indicating that the electronic ID was verified by the eID access control computer 110 to the token module. In some embodiments, the electronic identification control module may also provide electronic ID information such as the identification number and/or user data to the token module. The token module can then use the received data to obtain a payment token. [0139] At step 5, in response to receiving the eID authentication response message, the access device 135 can (e.g., via the token module) generate and transmit a token request message to the token service computer 120. The token request message (also referred to as a “second request”) can include the identification number, the user data, the confirmation data element indicating that the electronic ID was verified by the eID access control computer 110, and/or any other suitable information. 39 77627443V.1 PATENT Attorney Docket No.: 079900-1395618 Client Reference No.: 7160WO01 [0140] At step 6, the token service computer 120 can validate the token request message. For example, the token service computer 120 can verify the digital signature using a public key associated with the eID access control computer 110 to confirm that the eID access control computer 110 validated the electronic ID. The public key associated with the eID access control computer 110 can be included (e.g., in the form of a digital certificate issued by a certificate authority) in the token request message or retrieved from a public database. Additionally, the token service computer 120 can check a timestamp included in the token request message to verify that the eID access control computer 110 validated the electronic ID recently, within a predetermined time threshold (e.g., 10 seconds, 30 seconds, 1 minute, 5 minutes, 10 minutes, etc.). [0141] The token service computer 120 can identify an account based on the token request message. For example, in some embodiments, the token service computer 120 can identify, in a database, an account associated with a confirmation data element (e.g., a hash value and/or digital signature) provided by the eID access control computer 110 and included in the token request message. [0142] The token service computer 120 can then retrieve a payment token and/or a cryptogram associated with the identified account. In some embodiments, the token service computer 120 can generate a payment token and/or cryptogram and create an association between the generated payment token and the identified account. [0143] At step 7, the token service computer 120 can generate and transmit a token response message to the access device 135. The token response message can include the payment token, the cryptogram, and/or any other suitable information for processing a payment transaction (e.g., security code, an expiration date, a name, an address, a phone number). [0144] Thus, a payment token associated with a user’s electronic ID can be obtained by an access device 135 on behalf of the user, allowing an electronic ID to be usable for a payment transaction. While the user device 102 may have directly conducted an identity interaction with the access device 135, the results of the identity interaction can be used to proceed with a payment transaction. At this point, having converted the electronic ID information (which may not be correctly formatted 40 77627443V.1 PATENT Attorney Docket No.: 079900-1395618 Client Reference No.: 7160WO01 for processing by a transaction network) into a payment token (which is correctly formatted for processing by a transaction network), the transaction can be processed by submitting the payment token to the transaction network. [0145] The token module at the access device 135 can determine to provide the payment token to a transaction processing module at the access device 135. For example, the token module can provide the payment token, cryptogram, user data, and/or any other suitable information to the transaction processing module. The transaction processing module can then use the received data to submit the transaction for processing. [0146] In a typical transaction, the transaction processing module would receive the payment token through a series ADPU communications with a user device. In contrast, embodiments allow the access device 135 to receive the payment token from the token service computer 120, and therefore the ADPU messages for obtaining a payment token can be skipped. [0147] At step 8, the access device 135 can (e.g., via the transaction processing module) generate an authorization request message for the payment transaction. The authorization request message (also referred to as a “third request”) can include the payment token, cryptogram, a value (e.g., transaction amount), other transaction information (e.g., items purchased), merchant information (e.g., merchant name, location, etc.), and any other suitable information. [0148] The access device 135 can then transmit the authorization request message to the processing computer 142, which can process the transaction using the using the token. In some embodiments, transmitting the authorization request message to the processing computer 142 can take place through several iterative transmissions. For example, as a part of step 8, the access device 135 can transmit the authorization request message to the resource provider computer 140. At step 9, the resource provider computer 140 may forward the authorization request message to the transport computer 141. At step 10, the transport computer 141 may forward the authorization request message to the processing computer 142. [0149] At step 11, the processing computer 142 may perform one or more actions to process the transaction using the payment token. For example, the 41 77627443V.1 PATENT Attorney Docket No.: 079900-1395618 Client Reference No.: 7160WO01 processing computer 142 may generate a credential request message that requests the payment credential that is associated with the payment token. The credential request message includes the payment token, a token cryptogram, and/or any other suitable information received in the authorization request message. The processing computer 142 can transmit the credential request message to the token service computer 120. [0150] At step 12, the token service computer 120 can identify a payment credential associated with the payment token. For example, the token service computer 120 can look up an account associated with the payment token and retrieve a set of stored payment credentials associated with the account. The token service computer 120 may also verify that the payment token is valid, for example by checking an expiration time and/or validating a cryptogram. In some embodiments, the payment credentials, payment token, and electronic ID information (e.g., confirmation data element, identification number) may all be stored together in the same account or otherwise associated as a group. [0151] At step 13, the token service computer 120 can send the payment credentials to the processing computer 142 (e.g., in a credential response message). [0152] At step 14, the processing computer 142 can update the authorization request message to include the payment credentials. In some embodiments, the processing computer 142 may also remove the payment token from the authorization request message. The processing computer 142 may then forward the modified authorization request message to the authorizing entity computer 143. [0153] At step 15, the authorizing entity computer 143 may authorize or reject the transaction based on the payment credentials. For example, the authorizing entity computer 143 may identify the payment account associated with the payment credentials and/or payment token, and may determine whether there are sufficient funds. The authorizing entity computer 143 may then generate and send to the processing computer 142 an authorization response message indicating whether or not the transaction was authorized. The authorization response message may include the payment credentials, payment token, transaction details, merchant information, and/or any other suitable information. 42 77627443V.1 PATENT Attorney Docket No.: 079900-1395618 Client Reference No.: 7160WO01 [0154] At step 16, the processing computer 142 may forward the authorization response message to the transport computer 141. In some embodiments, before forwarding, the processing computer 142 may first modify the authorization response message to add the payment token and/or remove the payment credentials. This may involve additional communications with the token service computer 120 to obtain the payment token associated with the payment credentials. [0155] At step 17, the transport computer 141 may forward the authorization response message to the resource provider computer 140. [0156] At step 18, the resource provider computer 140 may determine that the transaction was successfully authorized based on the authorization response message. The resource provider computer 140 may then allow the purchased goods and/or services to be released to the user. Further, the resource provider computer 140 may store a transaction record including the payment token, user information, transaction details, and any other suitable information. In some embodiments, the resource provider computer 140 may forward the authorization response message to the access device 135 and/or the access device 135 may allow the purchased goods and/or services to be released to the user. [0157] At the end of the day, a normal clearing and settlement process can be conducted by the processing computer 142. A clearing process is a process of exchanging financial details between an acquirer and an authorizing entity to facilitate posting to a user's payment account and reconciliation of the user's settlement position. [0158] Embodiments include a number of alternatives, additions, and modifications to the method steps described above. For example, in some embodiments, certain processes described above with respect to the access device 135 can instead be performed by the resource provider computer 140. For example, generating an authorization request message as discussed above with respect to step 8 can be performed by the resource provider computer 140 after receiving the payment token and any other suitable data from the access device 135. [0159] The method above describes communications between the user device with respect to step 1, and then communications between the access device 135 43 77627443V.1 PATENT Attorney Docket No.: 079900-1395618 Client Reference No.: 7160WO01 and eID access control computer 110 with respect to steps 2-4. In other embodiments, steps 1-4 can be combined. For example, the eID access control computer 110 may support the access device 135 during communications with the user device 102, and/or the user device 102 may exchange messages with the eID access control computer 110 through the access device 135 to authenticate the electronic ID. For example, the user device 102 can and the eID access control computer 110 can verify the authenticity of the other device (e.g., mutual authentication), and/or exchanging of any suitable information. In some embodiments, the user device 102 and the eID access control computer 110 can mutually authenticate using corresponding private keys and certificates. Communications between the user device 102 and the eID access control computer 110 can be encrypted and otherwise protected through any suitable secure communication protocol, such as Basic Access Control (BAC), Passive Authentication (PA), Active Authentication (AA), Extended Access Control (EAC), and Supplemental Access Control (SAC). [0160] As discussed above with respect to step 6, the token service computer 120 can identify an account based on a confirmation data element included in the token request message. In other embodiments, instead of or in addition to using the confirmation data element, the token service computer 120 can identify an account associated with an identification number and/or user data included in the token request message. In some embodiments, the identification number and/or user data may be provided in an unencrypted form so that the token service computer 120 can look up the associated account. Alternatively, the identification number and/or user data can be provided in an encrypted form, and the token service computer 120 can look up the associated account by finding a matching encrypted identification number and/or user data stored in the database. [0161] As discussed above with respect to steps 11-13, the token service computer 120 can detokenize the payment token. In other embodiments, any other suitable entity may detokenize the payment token instead of the token service computer 120. For example, the processing computer 142 may detokenize the payment token using a local token record database before, or the authorizing entity computer 143 may detokenize the payment token. 44 77627443V.1 PATENT Attorney Docket No.: 079900-1395618 Client Reference No.: 7160WO01 [0162] As discussed above with respect to steps 14-15, the processing computer 142 can send the authorization request to the authorizing entity computer 143, and the authorizing entity computer 143 can authorize the transaction. In other embodiments, the processing computer 142 can authorize the transaction instead of the authorizing entity computer 143. For example, the processing computer 142 can perform some or all of step 15 as discussed above with respect to the authorizing entity computer 143. [0163] While payment tokens may typically be utilized to increase transaction security, embodiments allow the access device 135 to obtain the payment credentials at steps 5-7 instead of the payment token. The payment credentials can then be submitted in the authorization request message at step 8. [0164] Embodiments allow additional or alternative security measures to be utilized for the electronic ID authentication. For example, in some embodiments, step 1 can include prompting the user to enter a Personal Identification Number (PIN) and/or provide biometric input (e.g., a fingerprint scan, facial images, iris scan) at the user device 102 or the access device 135 for a biometric verification process. Biometric inputs can be validated by the user device 102, access device 135, and/or the eID access control computer 110 by comparing the biometric input with biometric template data stored at the user device 102, access device 135, and/or the eID access control computer 110. [0165] As described above with respect to step 1, during the initial communications between the user device 102 and access device 135, the user device 102 may provide an application identifier. The access device 135 may be configured to process multiple different application identifiers for different types of application. For example, in a separate second transaction, a second user device such as a mobile device with a payment application may be configured to provide a second payment token (or other payment credentials) to the access device 135. In this case, the second user device may provide an application identifier that identifies the payment application. The access device 135 may then determine that the application identifier identifies a payment application and does not identify an electronic ID application, and may determine to process the interaction using the transaction processing module and/or bypass the electronic identification control 45 77627443V.1 PATENT Attorney Docket No.: 079900-1395618 Client Reference No.: 7160WO01 module. The access device 135 may then receive a second credential (e.g., a second payment token) from the second user device, generate a second authorization request message comprising the second credential, and transmit the second authorization request message to the processing computer so that the processing computer can process the second transaction using the second credential. [0166] While the above method is described with respect to payment transactions, payment tokens, and payment authorization networks, embodiments also include other type of access and authorization. For example, an electronic ID can similarly be utilized for gaining physical access to a restricted physical area. Instead of a payment transaction, payment token, and a payment authorization network, the method can be used in the context of an access transaction, an access token, and an access authorization network. [0167] Embodiments of the invention provide for a number of technical advantages. Using embodiments of the invention, electronic IDs can become usable as payment instruments. A user’s electronic ID can be safely and securely linked to a user’s transaction account, such that two user accounts (e.g., identity and payment) which are typically separate can become associated. The linking enables the electronic ID information to be converted into a token or credential as part of a transaction process. As a result, electronic IDs which are not compatible with existing transaction systems (e.g., the confirmation data element is not formatted correctly for being included in an authorization request message) can become usable for transactions by being converted into a token or credential. [0168] Advantageously, this can be accomplished without any changes to existing identity authentication systems, without changes to existing transaction processing systems or flows, without requiring identity authentication servers or transaction servers to communicate with one another directly, without changes to existing hardware, and/or without compromising data security. Embodiments enable electronic IDs to be usable for payment by adding identity authentication software and protocols to an access device, and by storing certain user identity information as associated with a token or payment account at a token service computer. Through these relatively minor changes to access devices and token service computers, 46 77627443V.1 PATENT Attorney Docket No.: 079900-1395618 Client Reference No.: 7160WO01 embodiments can complete a method of converting an electronic ID authentication to a token which is then used for a payment transaction. [0169] With the electronic ID becoming usable for a new function of accessing a payment account for a transaction, the user is enabled to carry just the electronic ID and not carry a typical payment device. Further, the typical payment device may never be manufactured or provided to the user in the first place (e.g., as in a virtual account). Instead, the user’s payment account can be linked to the electronic ID, and the electronic ID can become the primary or only transactable physical device that is associated with the payment account. This eases the burden on the user by reducing the number of items the user keeps track of and carries. This also eases the burden on document-issuing organizations as they can issue less payment cards. [0170] Embodiments further advantageously protect electronic ID information that may be considered sensitive. For example, the process for authenticating an electronic ID can be protected through encryption and other security protocols. Further, the electronic ID information may not be shared, or may only be shared in a limited capacity. For example, the eID access control computer may only provide a confirmation data element, such as a verifiable hash value and/or digital signature, to the access device and/or token service computer. As a result, the access device and/or token service computer can be informed that the electronic ID is authentic and/or retrieve a token without exposing identity information. [0171] Embodiments also enable cross-border transactions with electronic IDs. As the electronic ID information is converted into tokens that are already formatted for existing transaction authorization systems, the tokens can be submitted across borders as usual, even though electronic ID formats may vary from country to country. [0172] Although the steps in the flowcharts and process flows described above are illustrated or described in a specific order, it is understood that embodiments of the invention may include methods that have the steps in different orders. In addition, steps may be omitted or added and may still be within embodiments of the invention. 47 77627443V.1 PATENT Attorney Docket No.: 079900-1395618 Client Reference No.: 7160WO01 [0173] 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. [0174] 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. [0175] 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. [0176] 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. 48 77627443V.1 PATENT Attorney Docket No.: 079900-1395618 Client Reference No.: 7160WO01 [0177] As used herein, the use of "a," "an," or "the" is intended to mean "at least one," unless specifically indicated to the contrary. 49 77627443V.1

Claims

PATENT Attorney Docket No.: 079900-1395618 Client Reference No.: 7160WO01 WHAT IS CLAIMED IS: 1. A method comprising: receiving, by an access device, a communication comprising electronic ID information from a user device in a transaction; transmitting, by the access device, an electronic ID authentication request message to an electronic ID access control computer; receiving, by the access device, an electronic ID authentication response message from the electronic ID access control computer; in response to receiving the electronic ID authentication response message, transmitting, by the access device, a token request message to a token service computer; receiving, by the access device, a token response message comprising a token from the token service computer; generating, by the access device, an authorization request message comprising the token and a value; and transmitting, by the access device, the authorization request message comprising the token to a processing computer, which processes the transaction using the using the token. 2. The method of claim 1, wherein the user device is a first user device, the transaction is a first transaction, and the authorization request message is a first authorization request message, and the method further comprises: receiving, by the access device, an application identifier from a second user device in a second transaction; determining, by the access device, that the application identifier does not identify an electronic ID application; receiving, by the access device, a credential from the second user device; generating, by the transaction processing module, a second authorization request message comprising the credential; and transmitting, by the access device, the second authorization request message to the processing computer, wherein the processing computer processes the second transaction using the credential. 50 77627443V.1 PATENT Attorney Docket No.: 079900-1395618 Client Reference No.: 7160WO01 3. The method of claim 1, wherein electronic ID authentication response includes a confirmation data element indicating that the user device is authentic. 4. The method of claim 3, wherein the confirmation data element includes a hash value generated by the electronic ID access control computer based on an identification number of the user device. 5. The method of claim 4, wherein the token request message includes the confirmation data element, and the token service computer identifies the token in a token vault based on the confirmation data element. 6. The method of claim 5, wherein the authorization request message is in an ISO 8583 format, the confirmation data element is not formatted for being included in the authorization request message, and the token is formatted for being included in the authorization request message. 7. The method of claim 1, wherein the token request message includes the electronic ID information, and the token service computer identifies the token based on the electronic ID information. 8. The method of claim 1, wherein the electronic ID authentication request message includes the electronic ID information, and the electronic ID information includes an identification number. 9. The method of claim 8, wherein the electronic ID information received from the user device is encrypted using a public key associated with the electronic ID access control computer, and the electronic ID access control computer decrypts the electronic ID information using a corresponding private key. 10. The method of claim 1, further comprising: 51 77627443V.1 PATENT Attorney Docket No.: 079900-1395618 Client Reference No.: 7160WO01 receiving, by the access device, an application identifier from the user device; determining, by the access device, that the application identifier is associated with an electronic ID application; in response to determining that the application identifier is associated with the electronic ID application, determining, by the access device, to process communications with the user device through an electronic ID control module; receiving, by the electronic ID control module, a digital signature or a cryptogram generated using a private key from the user device; and verifying, by the electronic ID control module, the digital signature or the cryptogram using a public key associated with the user device to authenticate the user device. 11. The method of claim 1, further comprising: generating, by the access device, a digital signature using a private key; and transmitting, by the access device, the digital signature to the user device, where the user device verifies the digital signature using a public key associated with the access device to authenticate the access device. 12. The method of claim 1, further comprising: generating, by the access device, a digital signature using a private key, wherein the electronic ID authentication request message includes the digital signature and the electronic ID access control computer verifies the digital signature using a public key associated with the access device to authenticate the access device. 13. The method of claim 1, wherein the user device is a passport or a driving license, the user device includes printed identity information, the user device includes an embedded microprocessor with encoded identity information, and the user device does not include credentials. 52 77627443V.1 PATENT Attorney Docket No.: 079900-1395618 Client Reference No.: 7160WO01 14. The method of claim 1, wherein the token response message further comprises a token cryptogram, and the authorization request message further comprises the token cryptogram. 15. An access device comprising: a processor; an electronic ID control module; a transaction processing module; and a computer readable medium, the computer readable medium comprising code executable by the processor to cause the processor to perform operations including: receiving a communication comprising electronic ID information from a user device in a transaction; transmitting an electronic ID authentication request message to an electronic ID access control computer; receiving an electronic ID authentication response message from the electronic ID access control computer; in response to receiving the electronic ID authentication response message, transmitting a token request message to a token service computer; receiving a token response message comprising a token from the token service computer; generating an authorization request message comprising the token and a value; and transmitting the authorization request message comprising the token to a processing computer, which processes the transaction using the using the token. 16. A method comprising: receiving, by an access device, a communication comprising electronic ID information from a user device in a transaction; transmitting, by the access device, an electronic ID authentication request message to an electronic ID access control computer; 53 77627443V.1 PATENT Attorney Docket No.: 079900-1395618 Client Reference No.: 7160WO01 receiving, by the access device, an electronic ID authentication response message from the electronic ID access control computer; and in response to receiving the electronic ID authentication response message, transmitting, by the access device, a registration request message to a token service computer, which stores an association between a token and the user device. 17. The method of claim 16, further comprising: receiving, by the access device, a credential from a user, where the registration request message includes the credential. 18. The method of claim 17, wherein the electronic ID authentication response message includes a confirmation data element indicating that the user device is authentic, the registration request message further includes the confirmation data element, and the association between the token and the user device includes the confirmation data element and the credential. 19. The method of claim 18, wherein the confirmation data element includes a hash value generated by the electronic ID access control computer based on an identification number of the user device and a certificate of the user device. 20. The method of claim 19, wherein the token service computer verifies the confirmation data element using a public key associated with the electronic ID access control computer. 54 77627443V.1