CN111937023A - Security authentication system and method - Google Patents

Abstract

A method is disclosed. The method comprises the following steps: receiving, by an access control server from an authentication requestor via a directory server, an authentication request including an account identifier, and information regarding a previous authentication method for the account identifier and a current authentication method for the account identifier associated with a transaction; performing, by the access control server, a risk analysis of the transaction based at least in part on the information and a threshold; authenticating, by the access control server, a user of the account identifier using the information, the account identifier, and a result of the risk analysis; modifying, by the access control server, an authentication response to include an authentication indicator; and transmitting, by the access control server, the authentication response to the authentication requestor.

Description

Security authentication system and method

Cross reference to related applications

This international application claims priority from us 62/650,180 provisional patent application No. 3/29/2018, the disclosure of which is incorporated herein by reference in its entirety for all purposes.

Background

Various systems and methods exist for authenticating a user in an online transaction. In some examples, an authorizing entity, such as an issuer, may authenticate a user conducting an online transaction with a resource provider, such as a merchant. An authorized entity may authenticate a user by requesting a password from the user. The user may then supply the password, and an authorized entity may authenticate the user. After the authorizing entity authenticates the user, the authorizing entity may provide an indication of the authentication (e.g., a positive or negative authentication result) to the resource provider. The resource provider may then provide an authorization request message to the authorizing entity for the transaction for the particular amount requested by the user. The authorizing entity also receives an indication of authentication and can use it as a decision to authorize or not authorize the interaction.

While the system described above is suitable for many situations, several improvements can be made. For example, the data used to authenticate the user is limited to the password we previously supplied to the authorized entity. If the password has been obtained by an unauthorized user, the unauthorized user may fraudulently perform a transaction with the resource provider. Accordingly, it would be desirable to provide a system and method that enables more efficient and effective authentication during online transactions.

Another problem with the conventional system described above is that the user is always asked for a password by the issuer. This can be cumbersome and requires several steps. Further, because a user may communicate with both a resource provider, such as a merchant, and an issuer during a single online transaction, it is possible that the communication may hang up or may time out. Accordingly, a better way to simplify processing by potentially removing the requirement of a user to enter a password to an issuer would be desirable.

Embodiments of the present invention address these and other problems, individually and collectively.

Disclosure of Invention

In some embodiments of the present invention, systems and methods are provided for utilizing an additional set of attributes for remote authentication processing of a transaction. An access control server according to embodiments of the present invention may receive and analyze the attributes to assist an authorized entity, such as an issuer, to quickly and accurately validate and authenticate online transactions. The first set of attributes may be associated with a previous authentication method (previous authentication method) of the requestor. The second set of attributes may be associated with a requestor's current authentication method (current authentication method). The requester previous authentication method may include a level of verification previously performed on a Primary Account Number (PAN) associated with the user. In some embodiments, the requestor prior authentication method may include authenticating the user and/or user device prior to conducting the current transaction. The second set of attributes associated with the requestor's current authentication method may include a level of authentication performed on the user during the current transaction. In some embodiments, the requestor's current authentication method may include the type of authentication performed on the user during the current transaction. According to at least one embodiment, the access control server may determine whether to authenticate the user in the transaction based on the requestor's previous authentication method and/or the requestor's current authentication method.

Some embodiments of the invention are directed to a method comprising: an authentication request including an account identifier is received by an access control server from an authentication requestor via a directory server, along with information regarding a previous authentication method for the account identifier and a current authentication method for the account identifier associated with the transaction. The method may further comprise: performing, by the access control server, a risk analysis of the transaction based at least in part on the information and the threshold. The method may further comprise: authenticating, by the access control server, the user of the account identifier using the information, the account identifier, and a result of the risk analysis. The method may further comprise: the authentication response is modified by the access control server to include an authentication indicator. The method may comprise: the authentication response is transmitted by the access control server to the authentication requestor.

In some embodiments, the information may further include transaction data for the transaction and personal information of the user associated with the transaction. The method may further comprise: generating, by a service provider application associated with the account identifier, a provisioning intent message including the user identifier, the service provider payment account identifier, and transaction data for the transaction. In some embodiments, the method may further comprise: an authentication signature for the transaction is generated by the service provider application based at least in part on input provided by a user associated with the transaction.

In some embodiments, the information regarding the previous authentication method for the account identifier and the current authentication method for the account identifier may be represented by one or more values appended to a message associated with the authentication request. The method may also include a value representing a unique type of authentication provided by a processing network, such as a payment processing network. In some embodiments, modifying the authentication response to include the authentication indicator includes setting a value in the authentication response representing the strength of the verification result of the transaction based at least in part on a previous authentication method for the account identifier and a current authentication method for the account identifier.

In some embodiments, the current authentication method for the account identifier associated with the transaction is performed by a service provider application associated with the account identifier and the transaction. The current authentication method may include at least one of: a first login to an account (e.g., a cardholder account) via a service provider application (e.g., a digital wallet application) using an issuer authentication process (e.g., an authentication process using an online bank password or credential), a second login to an account via a service provider application authentication process (e.g., an authentication process using a digital wallet application password), or a third login to an account via a service provider application using a third party service provider process. The previous authentication method may include at least one of: an accounting address verification process, a risk-based online authentication process analysis using device information from a user device associated with a current transaction process, and/or an online authentication process challenge process, tokenization process, or issuer inline preparation process used in username and password login preparation processes. In some embodiments, the results of the risk analysis include a negative verification of the transaction in response to determining that the risk analysis for the transaction is less than a threshold, or a positive verification of the transaction in response to determining that the risk analysis for the transaction is greater than a threshold.

Some embodiments of the invention may include an access control server comprising a processor and a computer-readable medium coupled to the processor, the computer-readable medium comprising code executable by the processor to perform a method. The method comprises the following steps: an authentication request including an account identifier is received by an access control server from an authentication requestor via a directory server, along with information regarding a previous authentication method for the account identifier and a current authentication method for the account identifier associated with the transaction. The method may further comprise: performing, by the access control server, a risk analysis of the transaction based at least in part on the information and the threshold. The method may further comprise: authenticating, by the access control server, the user of the account identifier using the information, the account identifier, and a result of the risk analysis. The method may further comprise: the authentication response is modified by the access control server to include an authentication indicator. The method may comprise: the authentication response is transmitted by the access control server to the authentication requestor.

Some embodiments of the invention are directed to a directory server comprising a processor and a computer-readable medium coupled to the processor for implementing a method. The method may comprise: receiving, by the directory server from the authentication requestor, an authentication request including the account identifier, and information regarding a previous authentication method for the account identifier and a current authentication method for the account identifier associated with the transaction, the current authentication method for the account identifier including an issuer signature for the transaction. The method may further comprise; the issuer signature of the information is verified by the directory server. The method may further comprise: the authentication response is modified by the directory server to include verification of the issuer signature. The method may comprise: transmitting, by the directory server, an authentication response to the authentication requestor, thereby bypassing the access control server for the transaction.

Another embodiment of the invention relates to an access control server performing the above method.

Further details regarding embodiments of the present invention can be found in the detailed description and drawings.

Drawings

FIG. 1 shows a flow chart illustrating a method according to an embodiment of the invention;

FIG. 2 shows a flow chart illustrating a method according to an embodiment of the invention;

FIG. 3 shows a flow chart illustrating a method according to an embodiment of the invention;

FIG. 4 shows an example state transition on a service provider application, according to an embodiment of the invention;

FIGS. 5A and 5B show example access control server logic, according to an embodiment of the invention; and

Detailed Description

Before discussing embodiments of the invention, some terms may be described in further detail.

A "server computer" may include a powerful computer or cluster of computers. For example, a server computer may be a mainframe, a minicomputer cluster, or a group of servers acting as a unit. In one example, the server computer may be a database server coupled to a network server. The server computer may be coupled to the database and may include any hardware, software, other logic, or combination of the preceding for servicing requests from one or more client computers. The server computer may include one or more computing devices, and may service requests from one or more client computers using any of a variety of computing structures, arrangements, and compilations.

An "authentication requestor" may be any suitable entity that requests authentication. In some embodiments, the resource provider, user device, or service provider application may be an authentication requestor.

A "service provider" may be any suitable entity that provides a service. In some embodiments, a "service provider" may be a digital wallet provider, an entity that provides access to resources such as location, data, or goods or services.

A "digital wallet" may include an electronic application or device that allows an individual to conduct e-commerce transactions. The digital wallet may store user profile information, payment credentials, bank account information, one or more digital wallet identifiers, etc., and may be used in various transactions such as, but not limited to, e-commerce, social networking, money transfer/personal payment, mobile commerce, close range payment, gaming, etc., for retail purchases, digital merchandise purchases, utility payments, purchases of games or gaming coupons from gaming websites or systems, transfers funds between users, etc. The digital wallet may be designed to simplify the purchase and payment process. The digital wallet may allow a user to load one or more payment cards onto the digital wallet for payment without entering an account number or presenting a physical card. The digital wallet may also store transaction records (e.g., electronic receipts).

An "access device" may be any suitable device that provides access to a remote system. The access device may also be used to communicate with a resource provider computer, an authentication computer, or any other suitable system. The access device may generally be located at any suitable location, for example, at the location of a resource provider or merchant. The access means may take any suitable form. Some examples of access devices include POS or point-of-sale devices (e.g., POS terminals), cellular phones, PDAs, Personal Computers (PCs), tablet PCs, hand-held dedicated readers, set-top boxes, Electronic Cash Registers (ECRs), Automated Teller Machines (ATMs), Virtual Cash Registers (VCRs), kiosks, security systems, access systems and terminals, and the like. The access device may use any suitable contact or contactless mode of operation to transmit or receive data from or associated with the user communication device. In some embodiments where the access device may comprise a POS terminal, any suitable POS terminal may be used and may include a reader, a processor, and a computer-readable medium. The reader may include any suitable contact or contactless mode of operation. For example, an exemplary reader may include a Radio Frequency (RF) antenna, an optical scanner, a barcode reader, or a magnetic stripe reader to interact with a payment device and/or a mobile device. Other examples of access devices include devices (e.g., locks, gates, access control boxes, etc.) that control actual access to a location (e.g., a race, a transfer station, a home, an office, a building, etc.) and software devices that control access to data or information.

An "authorization request message" may be an electronic message sent to the payment processing network and/or the issuer of the payment card to request authorization for a transaction. According to some embodiments, the authorization request message may comply with (international standards organization) ISO 8583, which is a standard for systems that exchange electronic transaction information associated with payments made by users using payment devices or payment accounts. The authorization request message may include an issuer account identifier that may be associated with the payment device or the payment account. The authorization request message may also include additional data elements corresponding to "identification information," including (by way of example only): a service code, a CVV (card verification value), a dCVV (dynamic card verification value), an expiration date, etc. The authorization request message may also include "transaction information," such as any information associated with the current transaction, e.g., transaction amount, merchant identifier, merchant location, etc., as well as any other information that may be used to determine whether to identify and/or authorize the transaction.

The "authorization response message" may be an electronic message reply to the authorization request message generated by the issuing financial institution or the payment processing network. By way of example only, the authorization response message may include one or more of the following status indicators: approval-the transaction is approved; decline-transaction not approved; or call center-suspend more informative responses, the merchant must call the toll free authorized telephone number. The authorization response message may also include an authorization code, which may be a code indicating that the transaction is approved that the credit card issuing bank returned to the merchant's access device (e.g., POS device) in response to the authorization request message in the electronic message (either directly or through the payment processing network). The code may be used as proof of authorization. As described above, in some embodiments, the payment processing network may generate or forward an authorization response message to the merchant.

"user" may include an individual operating a user device.

The "user device" may be any suitable device operated by a user. Suitable user devices may be portable and may communicate with external entities such as access devices. Examples of user devices include cards on which data is stored, mobile phones, laptop computers, transponders, wearable devices such as smart watches, automobiles with telecommunication capabilities, access cards, smart media, and the like. The payment device may be an example of a user device.

An "authorizing entity" may be the entity that authorizes the request. Examples of authorized entities may be issuers, government agencies, document repositories, access administrators, and so forth.

An "issuer" may generally refer to a business entity (e.g., a bank) that maintains a financial account for a user and often issues credit or debit cards to the user. The issuer may comprise a payment account issuer. The issuer may run an "authorization computer" to perform the actions described above.

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

An "access control server" may refer to a server computer that provides an authentication service to authenticate users conducting online transactions. The access control server may perform the requested authentication service for the issuer or other entity and provide the digitally signed response to the entity requesting authentication. The access control server may be shared or used by multiple entities. The entity may also have multiple access control servers, each associated with a different subset of users.

"directory server" may refer to a server computer that may be used to post messages in a transaction system. In some embodiments, the message posted by the directory server may contain registration and authentication information between the merchant plug-in (MPI) and the issuer access control server. The directory server may also determine whether the account may utilize an authentication service. In some embodiments, the directory server may be operated by a transaction service provider. According to various embodiments, the directory server may also be capable of tokenizing account data or may tokenize tokens.

A "processor" may refer to any suitable data computing device or devices. The processor may include one or more microprocessors that work together to implement the desired functionality. The processor may comprise a CPU including at least one high speed data processor sufficient to execute program components for performing user and/or system generated requests. The CPU may be a microprocessor, such as Athlon, Duron, and/or Opteron, of AMD; PowerPC from IBM and/or Motorola; cell processors by IBM and Sony; celeron, Itanium, Pentium, Xeon, and/or XScale from Intel; and/or the like.

The "memory" may be any suitable device or devices that can store electronic data. Suitable memory may include a non-transitory computer-readable medium that stores instructions executable by a processor to implement a desired method. Examples of memory may include one or more memory chips, disk drives, and the like. Such memories may operate using any suitable electrical, optical, and/or magnetic mode of operation.

Details of some embodiments of the invention will now be described.

Embodiments may utilize a unique set of attributes as additional data in the authentication process in an online transaction. The set of attributes may assist in the decision-making of an authorized entity, such as an issuer, during the online authentication process. The first set of attributes may be associated with a requestor's previous authentication method. The second set of attributes may be associated with a requestor's current authentication method.

The requester previous authentication method may include a level of verification previously performed on a Primary Account Number (PAN) associated with the user. In some embodiments, the requestor prior authentication method may be to authenticate the user and/or user device prior to initiation of the transaction.

The requestor prior authentication method may track the identification and verification (ID & V) performed on the user's account and may relay that information to an authorizing entity, such as an issuer associated with the account. Depending on what type of ID & V was performed in the past, the authorizing entity may assign a confidence level to the current transaction. Table 1 below lists example verification levels for prior authentication methods of the supplicant. In these examples, the length of the value may be two characters and the format may be a number. However, some embodiments may use more or fewer than two characters. Also, in some embodiments, the value associated with the authentication level may indicate other information. For example, attributes having values starting from '8' may be reserved for any suitable implementation.

Table 1-supplicant previous authentication method

As indicated above, the requestor previous authentication methods may include AVS, risk-based online authentication success, online authentication process challenge success, tokenization escalation, authorized entity online preparation, and the like. The online authentication process supplicant may also send a corresponding transaction reference value in order for an authorizing entity or Access Control Server (ACS) to verify the supplicant's previous authentication method in real time or during a dispute. The transaction reference value may indicate a transaction associated with a previous authentication method. During reporting or during disputes, certain values may be validated in real time by the ACS, while other values may be cross-referenced with its host system.

Table 2 below shows the requester previous authentication method data. In some embodiments, the length of the value of the requester previous authentication method data may be variable. For example, the first value may be 10 characters and the second value may be 32 characters. In some embodiments, the value may have a maximum number of characters (e.g., 36 characters). In some embodiments, the value may be a string.

Table 2-supplicant previous authentication method data

The second set of attributes associated with the requestor's current authentication method may be the level of authentication performed on the user during the current transaction. In some embodiments, the requestor's current authentication method may include the type of authentication performed on the user during the current transaction.

Table 3 below shows the supplicant current authentication method. In some embodiments, the value of the requester current authentication method data may be two characters in length. In some embodiments, the length of the value may be greater or less than 2. The format of the value may be a number.

TABLE 3 supplicant Current authentication method

The supplicant current authentication method data may have a predetermined maximum length (e.g., 2048 bytes). In some embodiments, the online authentication process requester authentication data may be in any suitable format. The supplicant current authentication method data may be a JWS formatted field to supplement the authentication method with data during the authentication process.

FIG. 1 shows a method according to an embodiment of the invention. FIG. 1 includes a user 102, a resource provider 104, a browser 106, a service provider application 108, a service provider computer 110, a processor computer 112 (e.g., an online authentication process server/merchant plug-in (MPI) combination), a directory server 114, and an access control server 116. It should be understood that for simplicity of illustration, a particular number of components are shown in FIG. 1. However, some embodiments may include more than one component per component, and some embodiments may include fewer or more components than specifically shown in fig. 1.

The user 102 may operate a user device (e.g., a computer or mobile phone) that may include a browser 106. In some embodiments, the user device may include a service provider application 108 (e.g., a digital wallet application). The browser 106 and the service provider application 108 may be in operative communication. The service provider application 108 may be in operative communication with a service provider computer 110. The service provider computer 110 may be in operative communication with a processor computer 112, and the processor computer 112 may be in operative communication with a directory server 114. Directory server 114 may be in operative communication with access control server 116. In some embodiments, the resource provider 104 may be in operative communication with the payment processor.

Resource provider 104 may operate a merchant computer. Resource provider 104 in fig. 1 may indicate a merchant computer. The merchant computer may comprise any suitable computing device. Examples of merchant computers may include an access device and/or an online merchant computer. In some embodiments, the merchant computer may comprise a web server computer hosting one or more websites associated with the merchant. The merchant computer may be configured to send and receive data as part of a transaction verification and authentication process for an online transaction conducted between a user and a merchant. The merchant computer may also be configured to generate or facilitate generation of the authorization request message, and may route the authorization request message, for example, to the payment processor.

Browser 106 may be a program or an application. For example, the browser 106 may be configured to display HTML files to the user 102 via a user device. The browser 106 may be used to navigate the internet.

The service provider application 108 may be a digital wallet application and may be used by a user associated with the digital wallet application to conduct financial transactions. The digital wallet may also be associated with authorizing and completing transactions, including encryption of sensitive payment data and personal user data. The application 108 may reside on a user device used by the user 102, or it may be a web application running on a web server computer.

The service provider computer 110 may be a server computer operated by an entity associated with the service provider application 108. In some embodiments, the service provider computer 110 may perform processing on the service provider application 108. In some embodiments, the service provider computer 110 may be a digital wallet server computer that provides support for digital wallet applications.

The processor computer 112 may be a processing network computer that may be configured to provide authorization services as well as clearing and settlement services for payment transactions. The processing network computer may include data processing subsystems, networks, and operations to support and deliver authorization services, exception file services, and clearing and settlement services. An exemplary payment processing network may include VisaNet^TM. Such as VisaNet^TMThe payment processing network is capable of processing credit card transactions, debit card transactions, and other types of commercial transactions. Visanet^TMSpecifically including a Visa Integrated Payment (VIP) system that processes authorization requests and a Base II system that performs clearing and settlement services. Further, the payment processing network may include a server computer, and any suitable wired or wireless telecommunications network may be used, including the internet. In some embodiments, the processing network computer may forward the authorization request received from the transfer computer to the authorizing entity computer via the communication channel. The processing network computer may further forward an authorization response message received from the authorizing entity computer to the transmitting computer. The processing computer 112 may also operate or be integrated with an MPI (merchant plugin).

Directory server 114 may be a server computer configured to route authentication messages from processor computer 112 to access control server 116, and route messages from access control server 116 back to processor computer 112.

The access control server 116 may be a remote server computer configured to perform remote authentication processing, for example, in response to a transaction. The access control server 116 may include a processor and a computer readable medium coupled to the processor. The access control server 116 may be associated with an issuer, which may be a bank that issues and maintains the user's account. The access control server 116 may verify (or authenticate) the account credentials during processing of the transaction. For example, the access control server 116 may verify the account credentials are valid. In some embodiments, the access control server 116 may perform risk analysis based on data received from a communication device operated by the user. The data may include communication device data, user identification data, geographic location data, transaction data, account credentials, and/or other similar data. The access control server 116 may use this data to determine the risk associated with the communication device or the risk associated with the account credentials being used for the transaction. In some embodiments, the access control server 116 may determine to verify the user 102 based on the requestor's previous authentication method and or the requestor's current authentication method.

The access control server 116 may have a predefined or user-defined risk threshold. When the risk level is below the risk threshold, the access control server 116 may provide an indication as follows: the user and/or user device is authenticated and the transaction can proceed. When the risk level is above the risk threshold, the access control server 116 may provide an indication as follows: the user and/or user device is not authenticated and the transaction should not proceed.

In some embodiments, the authentication scheme may include verifying user credentials via an issuer ACS (access control server). For example, the issuer ACS service may be in accordance with Visa^TMFor example, a 3D security protocol. The ACS may be associated with an issuer that may include registered user accounts and access information. The ACS may enable an issuer to authenticate a user during an online purchase, thereby reducing the probability of using a user account in a fraudulent manner. For example, the ACS may verify that the user is registered, perform user verification at the time of the transaction, and provide the digitally signed response to the merchant. In some embodiments, the authentication scheme may include using a transaction processing network consumer authentication service (e.g., Visa)^TMConsumer Authentication Service (VCAS)) verifies the account. For example, the VCAS service may authenticate the user on behalf of the issuer prior to the authorization process.

Prior to step 1, in fig. 1, the user 102 may have logged into the service provider application 108. The user 102 may use the browser 106 to navigate to a website associated with the resource provider 104. The user 102 may select goods or services to purchase. At step 1, the user 102 may click on the service provider application payment option. The service provider application payment options may be displayed on the user device. For example, the service provider application payment option may be a button selectable by the user 102. In some embodiments, the user 102 may be prompted to initiate the transaction in any suitable manner.

At step 2, after receiving input from the user 102, the browser 106 may launch a payment application (e.g., the service provider application 108). The browser 106 may then transmit the transaction details to the service provider application 108. The transaction details may include any suitable information. For example, the transaction details may include a transaction amount and a currency code.

At step 3, the service provider application 108 may generate a set intent message including the user ID, the service provider payment account ID, and the transaction details. The service provider application 108 may then transmit a setup intent message to the service provider computer 110.

At step 4, after receiving the setup intent message from the service provider application 108, the service provider computer 110 may forward the setup intent message to the processor computer 112.

At step 5, the processor computer 112 may transmit piData (personally identifiable information) to the service provider computer 110. The piData may include personal information of the user performing the transaction, such as name, address, and transaction data. In some embodiments, the processor computer 112 may determine the piData, address, and transaction data associated with the user ID.

At step 6, after receiving the piData, address, and transaction data from the processor computer 112, the service provider computer 110 may forward the piData, address, and transaction data to the service provider application 108.

At step 7, after receiving the piData, address, and transaction data, the service provider application 108 may display a card or other payment option on the screen of the user device. In some embodiments, the service provider application 108 may also display the shipping address.

At step 8, the user 102 may select a card and shipping address. The service provider application 108 may receive the selected card ID and the selected shipping address.

At step 9, after receiving input from the user 102, the service provider application 108 may perform authentication. For example, the service provider application 108 may authenticate the user 102. In some embodiments, this authentication may result in the requestor's current authentication method.

At step 10, after authentication, the service provider application 108 may transmit an update intention message to the service provider computer 110. The update intention message may include the selected card ID, the selected shipping address, and the intention ID.

At step 11, after receiving the renewal intent message from the service provider application 108, the service provider computer 110 may sign the transaction for authentication, thereby generating a service provider signature. The service provider signature and later online authentication process reply may provide secure transaction features such that a resource provider, such as a merchant, or a fraudster, may be prohibited from changing transaction details. For example, if service provider signing and authentication is performed for a $100 transaction, the merchant conducting the transaction cannot later attempt to update the amount at step 21 (e.g., by attempting to change the dollar amount to $1000) when it sends transaction information including CAVV (card verification value) and other information to the payment processor. Transaction details, service provider signatures and authentications, and subsequent authentications of the directory server and/or access control server are stored as data fields in the CAVV as described herein. According to some embodiments, new values may be set within the CAVV to confirm receipt and analysis of the requestor's previous authentication method and the requestor's current authentication method associated with transaction details provided by the service provider application that include the set dollar amount.

At step 12, the service provider computer 110 may include the service provider signature into the update intention message. The service provider computer 110 may then transmit an update intention message to the processor computer 112. The update intention message may include a selected card ID, a selected shipping address, an intention ID, and a service provider signature.

At step 13, after receiving the update intention message from the service provider computer 110, the processor computer 112 may generate an online authentication process message. The online authentication process message may include a PAN associated with the selected card ID, the selected shipping address, the transaction data, and the service provider signature. In some embodiments, the processor computer 112 may determine a PAN associated with the selected card ID and/or the selected shipping address. Processor computer 112 may then transmit an online authentication process message to directory server 114.

At step 14, directory server 114 may verify the service provider signature after receiving the online authentication process message from processor computer 112, thereby generating a verification result. Directory server 114 may have a public key or symmetric key corresponding to a private key or symmetric key held by service provider computer 108. After verifying the service provider signature, directory server 114 may transmit an online authentication process message including the PAN, the selected shipping address, the transaction data, the service provider signature, and the verification result to access control server 116.

At step 15, after receiving the online authentication process message from directory server 114, access control server 116 may generate an online authentication process reply message. The online authentication process reply message may include a Cardholder Authentication Verification Value (CAVV) and an ECI 5. In some embodiments, the ECI5 may be associated with an e-commerce transaction. In some embodiments, the access control server 116 may verify the service provider signature. The access control server 116 may set a value within the CAVV to confirm that the access control server 116 has received data from the requester's previous authentication method and the requester's current authentication method. This may signal to a party which entity has performed the authentication. In some embodiments, the issuer may implicitly trust the service provider application and online banking (OLB) password, and thus may provide a higher authorization rate when using the service provider application and OLB.

At step 16, after receiving the online authentication process reply from the access control server 116, the directory server 114 may forward the online authentication process reply to the processor computer 112.

At step 17, after receiving the online authentication process reply from the directory server 114, the processor computer 112 may generate an encrypted payment data message including the PAN, ECI5, and CAVV. The encrypted payment data message may be encrypted in any suitable manner. The processor computer 112 may then transmit the encrypted payment data message to the service provider computer 110. The service provider computer 110 may have a cryptographic key that corresponds to the cryptographic key used by the processor computer 112 to encrypt the payment data in the payment data message.

At step 18, after receiving the encrypted payment data message from processor computer 112, service provider computer 110 may forward the encrypted payment data message to service provider application 108.

At step 19, after receiving the encrypted payment data message from service provider computer 110, service provider application 108 may forward the encrypted payment data message to browser 106.

At step 20, after receiving the encrypted payment data message from the service provider application 108, the browser 106 may forward the encrypted payment data message to the resource provider 104.

At step 21, after receiving the encrypted payment data message from browser 106, resource provider 104 may transmit an authorization request message including the CAVV, ECI5, and PAN to a payment processor operating processor computer 112 to authorize the transaction. The authorization request message may pass through a transmitting computer operated by the acquirer before being received at the processor computer 112. After the processor computer 112 receives the authorization request message, it may forward the authorization request message to an authorization computer operated by an authorizing entity, such as an issuer. The authorization computer may then transmit an authorization response message back to the processor computer 112. In some embodiments, the resource provider 104 may receive the authorization response message from the processor computer 112 via the transmitting computer. At the end of the day or at some later time, clearing and settlement processes may be performed.

FIG. 2 shows a method according to an embodiment of the invention. The process flow in fig. 2 omits the service provider computer 110 shown in fig. 1.

FIG. 2 includes a user 102, a resource provider 104, a browser 106, a processor computer 112, a directory server 114, and an access control server 116.

Prior to step 1, the user 102 may have logged into the service provider application 108. At step 1, the user 102 may select a service provider application payment option.

At step 2, the browser 106 may receive a selection of an originating service provider application payment option. Browser 106 may generate a set intent message that includes the user ID, the service provider payment account ID, and the transaction details. The browser 106 can transmit the setup intent message to the processor computer 112.

At step 3, after receiving the setup intent message from the browser 106, the processor computer 112 may transmit the piData, address, and transaction data to the browser 106.

At step 4, the browser 106 may display the card to the screen of the user device. In some embodiments, browser 106 may also display the shipping address.

At step 5, the user 102 may select a card and shipping address.

At step 6, after receiving input from the user 102, the browser 106 may initiate an authentication process. For example, the service provider application 108 may authenticate the user 102.

At step 7, after authentication, the browser 106 may transmit an update intention message to the processor computer 112. The update intention message may include the selected card ID, the selected shipping address, and the intention ID.

At step 8, the processor computer 112 may wait for the service provider computer 110 to sign the transaction for authentication, thereby generating a service provider signature. The processor computer 112 may generate an online authentication process message including the PAN, the selected shipping address, the transaction data, the service provider signature, the requester previous authentication method data (dsreqpireminmethod), and the requester current authentication method data (dsreqphetenmethod). Processor computer 112 may transmit an online authentication process message to directory server 114. For example, the requestor previous authentication method data may include information indicating that the user 102 was previously registered to use the service provider application via online banking with an authorized entity and may have used OLB (online banking) username/password authentication. The requestor's current authentication method may include information indicating that the user clicked the service provider application button during checkout and opted to log in using the authorized entity password. In some embodiments, the requestor previous authentication method may be denoted as requeststor priorauthentication method 82. The supplicant current authentication method may be denoted as requestorauthentificationmethod 80.

At step 9, directory server 114 may verify the service provider signature after receiving the online authentication process message from processor computer 112. Directory server 114 may then include the verification result in the online authentication process message. Directory server 114 may transmit the online authentication process message to access control server 116. The access control server 116 may receive an authentication request including an account identifier from an authentication requestor via the directory server 114, along with information regarding previous authentication methods for the account identifier or the user of the account identifier. For example, the authentication requestor may be a service provider computer 110 operable by a service provider. The authentication request may be an online authentication procedure message. The information regarding the previous authentication method for the account identifier or the user of the account identifier may be a requester previous authentication method.

At step 10, the access control server 116 may evaluate the online authentication process message. The access control server 116 may determine whether to authenticate the user and/or user device based on the requestor's previous authentication method and/or the requestor's current authentication method. For example, if the requestor previous authentication method is 82 and the requestor current authentication method is 80 as described above, the access control server 116 may determine not to further authenticate the user 102. The access control server 116 can determine a confidence level of the probability that the user 102 is the correct user and/or the user device is the correct user device. For example, for the above example, the confidence level that the transaction is authentic may be "very high". This may mean that there is no reason to deny the transaction unless the access control server 116 uses other data to determine that the cardholder has been compromised (e.g., account hijacking). The access control server 116 may be located within the CAVV to indicate the determination of the authenticity of the user 102. In some embodiments, the access control server 116 may authenticate the user of the account identifier using the information (e.g., the requestor's previous authentication method and/or the requestor's current authentication method) and the account identifier.

At step 11, the access control server 116 may generate an online authentication process reply that includes the CAVV and the ECI 5. Access control server 116 may then transmit an online authentication process reply to directory server 114. In some embodiments, the access control server 116 may transmit an authentication indicator to the authentication requestor. The authentication indicator may be a CAVV. In some embodiments, the authentication requestor may be the processor computer 112.

At step 12, after receiving the online authentication process reply, directory server 114 may forward the online authentication process reply to processor computer 112.

At step 13, after receiving the online authentication process reply from the directory server 114, the processor computer 112 may generate encrypted payment data. The encrypted payment data may include PAN, ECI5, and cavw. Processor computer 112 may then transmit the encrypted payment data to browser 106. In some embodiments, the encrypted payment data may be encrypted using any suitable method.

At step 14, after receiving the encrypted payment data, browser 106 may forward the encrypted payment data to resource provider 104. At step 15, after receiving the encrypted payment data, the resource provider 104 may transmit the CAVV, ECI5, and PAN to a payment processor, such as the processor computer 112. In some embodiments, the resource provider 104 may decrypt the encrypted payment data. In other embodiments, the resource provider 104 may forward the encrypted payment data to the payment processor. Further payment processing steps are described above in the discussion of step 21 in fig. 1, and this description is incorporated herein.

FIG. 3 shows a method according to an embodiment of the invention. Fig. 3 illustrates an authorization computer 118 (e.g., an issuer computer), which is not shown in fig. 1 or 2.

FIG. 3 includes a user 102, a resource provider 104, a browser 106, a processor computer 112, a directory server 114, an access control server 116, and an authorization computer 118.

Authorization computer 118 may be a server computer operated by an issuer. In some embodiments, authorization computer 118 may be an authorization computer.

At step 1, a user 102 may access a website of a resource provider 104 via a browser 106. At step 2, browser 106 may load the service provider web application after communicating with processor computer 112.

At step 3, the browser 106 may determine whether the user 102 is supported for authentication with an authorized entity for the service provider application. If the user 102 is supported, the browser 106 may transmit an authenticated request to the processor computer 112 at step 4.

At step 5, after receiving the authenticated request from the browser 106, the processor computer 112 may transmit the authorization entity URL to the browser 106.

At step 6, browser 106 may communicate with authorization computer 118. Browser 106 can transmit an authorization request to authorization computer 118. Authorization computer 118 may respond to the authorization request by transmitting a message to browser 106.

At step 7, the user 102 may enter or otherwise provide user credentials to the browser 106. In some embodiments, browser 106 may prompt user 102 to enter user credentials (e.g., username and password, biometric information, or other suitable user credentials).

At step 8, after receiving the user credentials, the browser 106 may transmit an issuer login logic message to the authorization computer 118. The issuer login logic may include transaction details.

At step 9, after receiving the transaction details, authorization computer 118 may generate an OpenID and may connect to the token. Authorization computer 118 may then sign the transaction for authentication, at step 10, to generate an authorization entity (e.g., issuer) signature.

At step 11, authorization computer 118 may transmit a return token including the OpenID and the issuer signature to browser 106.

At step 12, after receiving the return token, the browser 106 may continue the service provider application flow.

At step 13, the user 102 may select a card and shipping address for the transaction. The selected card and the selected shipping address may be transmitted to the processor computer 112 in any suitable manner. For example, the selected card and the selected shipping address may be transmitted via browser 106.

At step 14, after receiving the selected card and the selected shipping address, the processor computer 112 may generate an online authentication process message including the PAN associated with the selected card, the selected shipping address, the transaction data, and the issuer signature. Processor computer 112 may then transmit an online authentication process message to directory server 114.

At step 15, upon receiving the online authentication process message from authorization computer 118, directory server 114 may verify the issuer signature, thereby generating a verification result. Directory server 114 may add the verification result to an online authentication process message, which may include the PAN, the selected shipping address, transaction data, the issuer signature, and the verification result. Directory server 114 may then transmit the online authentication process message to access control server 116.

At step 16, after receiving the online authentication process message from the directory server 114, the access control server 116 may generate an online authentication process reply including the CAVV and ECI 5. The access control server 116 may determine the CAVV and ECI5 for the transaction. In some embodiments, the access control server 116 may verify the issuer signature.

At step 17, access control server 116 may then transmit an online authentication process reply to directory server 114.

At step 18, after receiving the online authentication process reply from the access control server 116, the directory server 114 may forward the online authentication process reply to the processor computer 112.

At step 19, after receiving the online authentication process reply from the directory server 114, the processor computer 112 may generate an encrypted payment data message including the PAN, ECI5, and CAVV. Processor computer 112 may then transmit the encrypted payment data to browser 106.

At step 20, after receiving the encrypted payment data message from the processor computer 112, the browser 106 may forward the encrypted payment data message to the resource provider 104.

At step 21, after receiving the encrypted payment data message from browser 106, the merchant may transmit the CAVV, ECI5, and PAN to the payment processor. Further payment processing steps are described above in the discussion of step 21 in fig. 1, and this description is incorporated herein.

Table 4 below shows an example use case along with an associated confidence level that the access control server 116 can determine. Attributes of the use case are also presented.

TABLE 4 example use cases

The payload attributes included in the message may include a timestamp, a Cardholder Verification Method (CVM), a device ID, a service provider ID, an account ID, a merchant name, a transaction amount, a currency code, a currency index, a digital signature, an algorithm, and/or an X509 certificate. In some embodiments, some payload attributes may be provided. In other embodiments, all payload attributes may be provided.

The timestamp may be the date and time of the user's authentication. In some embodiments, the timestamp may be in the UTC. The time stamp may be 14 characters in length. In some embodiments, the timestamp may have any suitable number of characters. The timestamp may be in the format of YYYYMMDDHHMMSS.

The CVM may be an enumeration of different cardholder verification methods. In some embodiments, the CVM may have a length of 2 characters. In some embodiments, any suitable length may be used. For example, a CVM for using a password may be 0x01 ═ password. Other examples include: 0x02 ═ mode, 0xB0 ═ biometric: fingerprint, 0xB 1-biometric: iris, 0xB2 biometric: retina, 0xB3 biometric: face, 0xB4 biometric: speech, and 0xBF ═ biometric; and others.

The device ID may be a D identifier associated with the device. The device ID may be conditional on the token to which the device is bound and may be optional for all other tokens. The device ID may have a variable length and may be a character string. In some embodiments, the device ID may have a maximum number of characters (e.g., 24 characters).

The service provider ID may be an identifier associated with the service provider. The service provider may be an authenticator. The service provider ID may be conditional on the device-bound token and may be optional for all other tokens. In some embodiments, the length of the service provider ID may be variable. In other embodiments, the length of the service provider ID may have a maximum length (e.g., 36 characters).

The account ID may be an identifier associated with the account. The account ID may have a variable length. In some embodiments, the account ID may have a maximum length (e.g., 24 characters).

The merchant name may be a name associated with the merchant. The merchant name may have a variable length. In some embodiments, the merchant name may have a maximum length (e.g., 24 characters).

The transaction amount may be an amount associated with the transaction. The transaction amount may have a variable length. In some embodiments, the transaction amount may have a maximum length (e.g., 48 characters). The transaction amount may be a number.

The currency code may be a code associated with a currency used in the transaction. The currency code may have a variable length. In some embodiments, the currency code may have a maximum length (e.g., 3 characters). The currency code may be in the format ISO 4217.

The currency index may be a code associated with a currency used in the transaction. The monetary index may have a variable length. In some embodiments, the currency index may have a maximum length (e.g., 1 character). The currency code may be in the format ISO 4217.

A digital signature may be a mathematical scheme used to indicate the authenticity of a digital message or document. A valid digital signature may indicate to a third party that the message was created by a known sender, and that the sender cannot deny that the message has been sent, and that the message has not been altered during transit. The digital signature may have a variable length. In some embodiments, the digital signature may have a maximum length (e.g., 64 bytes).

The algorithm may be an algorithm related to encryption. For example, the algorithm may be ES256-ECDSA using P-256 and SHA-256. In some embodiments, the algorithm may be ES384-ECDSA using P-384 and SHA-384. In other embodiments, the algorithm may be ES512-ECDSA using P-521 and SHA-512. In still other embodiments, the algorithm may be PS256-RSASSA-PSS using SHA-256 and MGF1 and SHA-256.

The X509 certificate may be a standard that defines the format of a public key certificate. In some embodiments, X509 certificates may be used outside of the JWS structure. The X509 certificate may have a variable length. In some embodiments, an X509 certificate may have a maximum length (e.g., 1024 bytes).

In some embodiments, the maximum total size of all fields may be:

14 (timestamp) +2(CVM) +24 (device ID) +36 (wallet ID) +24 (account ID) +24 (merchant) +48 (amount) +3 (currency) +1 (index) +64 (signature) +1024 (certificate) ═ 1264 bytes.

FIG. 4 shows an example state transition on a service provider application according to an embodiment of the present invention. The state transition 400 includes a flow beginning at 402, where a user may perform one or more pre-or previous authentication methods for an account or account identifier that is ultimately relayed to an issuer. Based on the method used to verify the user's prior or previous authentication method, the issuer may assign a confidence level to the transaction. In state transition 400, the user may manually authenticate himself with AVS authentication by authenticating the address with the service provider application site at 404. The user may upgrade or otherwise change their previous authentication method at any time that will be reflected in the application of the service provider of the user device to subsequent authentication messages between the access control server and/or directory server and the issuer at the time of the transaction. For example, the user may change their previous authentication method from AVS verification 404 to risk-based online authentication process success 406 or online authentication process challenge success 408.

In an embodiment, the circle at 410 of fig. 4 represents a state transition from a low to medium confidence level prior authentication method to a high confidence level prior authentication method (e.g., tokenization step up 412 or authorization entity inline preparation 414). The state transition of fig. 4 also shows a state transition or initial state transition to the higher confidence level prior authentication methods 412 and 414 via lines 416 and 418. Lines 416 and 418 represent a transition to a higher form of prior authentication method to enable the user to participate while not having to perform any of the other processes (404-408). According to at least one embodiment, a user may transition from a higher confidence authentication process state to a lower confidence authentication process (e.g., from tokenization step up to AVS verification). In such cases, the online authentication process requester previous authentication methods will be updated and the appropriate attributes will reflect this update, which may affect the subsequent transaction process for the user or account identifier.

Fig. 5A and 5B show example access control server logic, according to an embodiment of the invention. The access control server logic 500 of fig. 5A and 5B includes a visual representation of the use case described above with reference to table 4. For example, logic flow 500, which includes AVS verification 502, produces a medium confidence level 504, which results in steps 14 and 15 being replied to for the authentication message or online authentication process of fig. 1, the online authentication process requester previous authentication method being set to data value "81" and the online authentication process requester current authentication method being set to data value "81". Other logic flows included in logic flow 500, such as online authentication process challenge success 506, may yield a high confidence 508 or a very high confidence 510 based on whether the account is authenticated using service provider application authentication or issuer authentication.

The access control server and/or directory server described above may be configured to implement methods and/or processes for authenticating transactions according to embodiments of the present invention. The access control server and/or directory server and elements described herein with reference to fig. 1-5A and 5B may operate one or more computer devices to facilitate the functions described herein. The access control server and directory server may each include a processor and a computer readable medium including code executable by the processor for implementing any of the methods described herein.

Embodiments of the present invention provide a number of advantages. A first advantage is that the access control server 116 may determine not to perform additional authentication of the user, thus saving resources rather than performing redundant authentication. Furthermore, the access control server 116 may receive additional information, which may allow it to make more accurate determinations about the authenticity of the user than previous methods. Embodiments of the present invention allow the access control server 116 to receive this additional information without receiving large amounts of data that slows down the system. For example, in some embodiments, the maximum total size of all fields may be 1264 bytes. In conventional systems, the access control server 116 may need to request or otherwise obtain hundreds of data points to perform a similar risk analysis and verification process. In the current embodiment of the present invention, the access control server 116 may perform the risk analysis and verification process by receiving the requester previous authentication method and the requester current authentication method represented by the small data value. Furthermore, the results of this analysis can be transmitted and signaled by setting values within the CAVV to signal to the issuer that a verification process using the above-mentioned data points has been performed, thus improving the conversion rate of transactions trusted by the issuer. Because the data being transmitted to represent the requestor's previous authentication method and the requestor's current authentication method is performed by updating the attribute values, the system architecture of the payment transaction processing does not need to be altered or updated to achieve the desired results, thereby increasing the probability of adoption by parties such as merchants.

Embodiments of the present invention are also improved over conventional systems that may only use an issuer-based password to authenticate a user in a transaction. For example, if an unauthorized person steals the user's issuer password and attempts to conduct a transaction, other data such as previous authentication method information (indicating a high probability of fraud) may be used by the access control server in embodiments of the invention to possibly score the transaction as risky, even though the asserted user has supplied the correct issuer password. Accordingly, embodiments of the present invention may identify potentially fraudulent transactions that may not be detected using conventional systems.

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

The methods and processes described herein are exemplary in nature, and methods and processes according to some embodiments may perform one or more of the steps in a different order than described herein, include one or more additional steps not specifically described, omit one or more steps, combine one or more steps into a single step, split one or more steps into multiple steps, and/or any combination thereof.

It will be appreciated that some embodiments as described above may be implemented in the form of control logic using computer software in a modular or integrated manner. . Based on the disclosure and teachings provided herein, a person of ordinary skill in the art will know and appreciate other ways and/or methods to implement the present invention using hardware and a combination of hardware and software.

Any of the software components or functions described herein may be implemented as software code executed by a processor using, for example, conventional or object-oriented techniques, and using any suitable computer language (e.g., Java, C + +, or Perl). The software code may be stored as a series of instructions or commands on a computer readable medium, such as a Random Access Memory (RAM), a Read Only Memory (ROM), a magnetic medium such as a hard drive or floppy disk, or an optical medium such as a CD-ROM. Any such computer-readable media may reside on or within a single computing device, and may exist on or within different computing devices within a system or network.

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

The recitation of "a" or "the" is intended to mean "one or more" unless explicitly indicated to the contrary.

Claims (21)

1. A computer-implemented method, comprising:

receiving, by an access control server from an authentication requestor via a directory server, an authentication request including an account identifier, and information regarding a previous authentication method for the account identifier and a current authentication method for the account identifier associated with a transaction;

performing, by the access control server, a risk analysis of the transaction based at least in part on the information and a threshold;

authenticating, by the access control server, a user of the account identifier using the information, the account identifier, and a result of the risk analysis;

modifying, by the access control server, an authentication response to include an authentication indicator; and

transmitting, by the access control server, the authentication response to the authentication requestor.

2. The computer-implemented method of claim 1, wherein the information further comprises transaction data for the transaction and personal information of the user associated with the transaction.

3. The computer-implemented method of claim 1, further comprising generating, by a service provider application associated with the account identifier, a set intent message comprising a user identifier, a service provider payment account identifier, and transaction data for the transaction.

4. The computer-implemented method of claim 3, further comprising generating, by the service provider application, an authentication signature for the transaction based at least in part on input provided by the user associated with the transaction.

5. The computer-implemented method of claim 1, wherein the information about the previous authentication method for the account identifier and the current authentication method for the account identifier is represented by one or more values appended to a message associated with the authentication request.

6. The computer-implemented method of claim 5, wherein a value of the one or more values represents a unique type of authentication provided by a processing network.

7. The computer-implemented method of claim 1, wherein modifying the authentication response to include the authentication indicator comprises: setting a value in the authentication response representing a strength of a verification result of the transaction based at least in part on the previous authentication method for the account identifier and the current authentication method for the account identifier.

8. The computer-implemented method of claim 1, wherein the current authentication method for the account identifier associated with the transaction is performed by a service provider application associated with the account identifier and the transaction.

9. The computer-implemented method of claim 1, wherein the current authentication method comprises at least one of: the method may include logging into the account a first time using an authorized entity authentication process, a second time via a service provider application authentication process, or a third time using a third party authentication process.

10. The computer-implemented method of claim 1, wherein the previous authentication method comprises at least one of: an accounting address verification process, a risk-based online authentication process analysis using device information from a user device associated with a transaction process, an online authentication process challenge process including username and password login preparation, a tokenization process, or an issuer online preparation process.

11. The computer-implemented method of claim 1, wherein the results of the risk analysis comprise: a negative verification of the transaction in response to determining that the risk analysis of the transaction is less than the threshold, or a positive verification of the transaction in response to determining that the risk analysis of the transaction is greater than the threshold.

12. An access control server, comprising:

a processor; and

a computer-readable medium coupled to the processor, the computer-readable medium comprising code executable by the processor to implement a method comprising:

receiving, by an access control server from an authentication requestor via a directory server, an authentication request including an account identifier, and information regarding a previous authentication method for the account identifier and a current authentication method for the account identifier associated with a transaction;

performing, by the access control server, a risk analysis of the transaction based at least in part on the information and a threshold;

authenticating, by the access control server, a user of the account identifier using the information, the account identifier, and a result of the risk analysis;

modifying, by the access control server, an authentication response to include an authentication indicator; and

transmitting, by the access control server, the authentication response to the authentication requestor.

13. The access control server of claim 12, wherein the information further comprises transaction data for the transaction and personal information of a user associated with the transaction.

14. The access control server of claim 12, wherein the method further comprises generating, by a service provider application associated with the account identifier, a set intent message comprising a user identifier, a service provider payment account identifier, and transaction data for the transaction.

15. The access control server of claim 14, wherein the method further comprises generating, by the service provider application, an authentication signature for the transaction based at least in part on input provided by a user associated with the transaction.

16. The access control server of claim 12, wherein the information about the previous authentication method for the account identifier and the current authentication method for the account identifier is represented by one or more values appended to a message associated with the authentication request.

17. The access control server of claim 12, wherein the value of the one or more values represents a unique type of authentication provided by a payment processing network.

18. The access control server of claim 12, wherein modifying the authentication response to include the authentication indicator comprises: setting a value in the authentication response representing a strength of a verification result of the transaction based at least in part on the previous authentication method for the account identifier and the current authentication method for the account identifier.

19. The access control server of claim 12, wherein the results of the risk analysis comprise: a negative verification of the transaction in response to determining that the risk analysis of the transaction is less than the threshold, or a positive verification of the transaction in response to determining that the risk analysis of the transaction is greater than the threshold.

20. A directory server, comprising:

a processor; and

a computer-readable medium coupled to the processor, the computer-readable medium comprising code executable by the processor to implement a method comprising:

receiving, by the directory server from an authentication requestor, an authentication request including an account identifier, and information regarding a previous authentication method for the account identifier and a current authentication method for the account identifier associated with a transaction, the current authentication method for the account identifier including a signature for the transaction;

verifying, by the directory server, the signature of the information;

modifying, by the directory server, an authentication response to include the verification of the signature; and

transmitting, by the directory server, the authentication response to the authentication requestor, thereby bypassing an access control server for the transaction.

21. A method, comprising:

receiving, by a directory server from an authentication requestor, an authentication request including an account identifier, and information regarding a previous authentication method for the account identifier and a current authentication method for the account identifier associated with a transaction, the current authentication method for the account identifier including a signature for the transaction;

verifying, by the directory server, the signature of the information;

modifying, by the directory server, an authentication response to include the verification of the signature; and

transmitting, by the directory server, the authentication response to the authentication requestor, thereby bypassing an access control server for the transaction.

Images