Authenticator application for consent framework

Abstract

A method (1000) for authenticating an operation within a consent framework includes obtaining an operation request (142) that requests a service application (140) to access a remote entity (130) to perform an operation (138). The method also includes issuing, by the service application, an authentication request (152) prior to the remote entity performing the operation, the authentication request (152) requesting an authenticator application (150) to obtain user authentication credentials (154) for authenticating a user (12). The method also includes encrypting, by the authenticator application, the obtained user authentication credentials using a public key (132) of the remote entity. The service application is restricted from obtaining the user authentication credentials in unencrypted form. The method also includes providing, by the authenticator application, the encrypted user authentication credentials to the service application and transmitting, by the service application, the operation request and the encrypted user authentication credentials to the remote entity.

Description

Technical Field

[0001] The present disclosure relates to a cross-application authenticator application for securely authenticating any number of applications. Background Art

[0002] Real-time payment (RTP) is a financial transaction that allows the payee to receive payment within seconds (i.e., "real time") of the sending financial institution initiating the transaction. These payment systems are typically maintained by an RTP network, which is typically a central institution that facilitates funds across issuers, similar to the credit card network that handles exchange and settlement. RTP is typically performed via a user device (e.g., a mobile phone) running a payment application (app) to instantly transfer funds from one user's account at a financial institution to another user's account at a different or the same financial institution. These payment applications typically access the RTP network via an application programming interface (API). The popularity of RTP has increased significantly, and as the number of transactions has soared, the number of competing payment applications has also increased. It is not uncommon for users to have multiple independent payment applications on the same user device, each of which is authorized to access one or more users' accounts. Summary of the Invention

[0003] One aspect of the present disclosure provides a method for authenticating an operation within a consent architecture. The method includes obtaining an operation request from data processing hardware of a user device running a service application and an authenticator application, the operation request requesting the service application to access a remote entity to perform an operation. The operation request includes a remote entity identifier identifying the remote entity and operation information associated with the operation. The method also includes, before the remote entity performs the operation, issuing an authentication request by the service application running on the data processing hardware, the authentication request requesting the authenticator application to obtain a user authentication credential of a user of the user device associated with the remote entity for use in authenticating the user. The method also includes, by the authenticator application running on the data processing hardware, encrypting the obtained user authentication credential using a public key of the remote entity, thereby restricting the service application from obtaining the user authentication credential in an unencrypted form. The method also includes, by the authenticator application running on the data processing hardware, providing the encrypted user authentication credential to the service application, and, by the service application running on the data processing hardware, transmitting the operation request and the encrypted user authentication credential to the remote entity. When received by the remote entity, the operation request and the encrypted user authentication credential cause the remote entity to decrypt the encrypted user authentication credential using the remote entity's private key and verify the decrypted user authentication credential.

[0004] Implementations of the present disclosure may include one or more of the following optional features. In some implementations, the service application includes a payment application and the remote entity includes a financial institution associated with the user. The operation request requesting the service application to access the remote entity includes an electronic payment request requesting the payment application to initiate an electronic payment from the financial institution to a payee. In some examples, the operation information includes at least one of a description of the electronic payment, a value / amount of the electronic payment, at least a portion of a unique account identifier identifying an account associated with the user at the financial institution, or a payee identifier identifying the payee.

[0005] Optionally, the remote entity includes a record data store storing private information associated with the user, and the operation request requesting the service application to access the remote entity includes an information retrieval request requesting the service application to retrieve at least some of the private information from the record data store. The private information may include private records associated with the user. The private information may be information that the user wishes to keep confidential or that the service provider is obligated to keep confidential. In some embodiments, the method further includes, after encrypting the obtained user authentication credentials using the public key of the remote entity, re-encrypting the encrypted user authentication credentials using the public key associated with the verification network of the remote entity by the authenticator application running on the data processing hardware.

[0006] In some examples, the method further includes, after encrypting the obtained user authentication credentials using the public key of the remote entity, signing the encrypted user authentication credentials using the private key of the user device by an authenticator application running on the data processing hardware. The public key of the user device can be registered with the remote entity. The public key of the user device corresponds to the private key of the user device and is used by the remote entity to verify the signature of the encrypted user authentication credentials. Optionally, encrypting the obtained user authentication credentials using the public key of the remote entity also includes encrypting the operation request and the user authentication credentials together using the public key of the remote entity.

[0007] In some embodiments, the method further includes, before encrypting the obtained user authentication credentials, issuing, by an authenticator application running on the data processing hardware, a user device unlock challenge to the user. The authentication request issued by the service application may include an authorization token, which the authenticator application uses to authenticate the service application before obtaining the user authentication credentials.

[0008] Optionally, the method further includes, after transmitting the operation request and the encrypted user authentication credentials to the remote entity, receiving a challenge request from the remote entity at the service application running on the data processing hardware. The challenge request requests additional user authentication credentials from the user. The method may also include the service application running on the data processing hardware calling an authenticator application to obtain additional user authentication credentials from the user, and the authenticator application running on the data processing hardware encrypting the obtained additional user authentication credentials using the public key of the remote entity. The method may also include the authenticator application running on the data processing hardware providing the encrypted additional user authentication credentials to the service application, and the service application running on the data processing hardware sending a challenge response including the encrypted additional user authentication credentials to the remote entity. When the challenge response is received by the remote entity, the remote entity decrypts the encrypted additional user authentication credentials using the private key of the remote entity and verifies the decrypted additional user authentication credentials.

[0009] In some examples, the remote entity is configured to perform the operation based on the operation request after verifying the decrypted user authentication credentials and the decrypted additional user authentication credentials. The remote entity can be configured to transfer the electronic payment to the payee after verifying the decrypted user authentication credentials.

[0010] In some examples, the method further includes binding the user's identity to the user device by an authenticator application running on the data processing hardware. The binding may include receiving a service registration request from a service application running on the data processing hardware. The service registration request includes a user identifier and a service application identifier. The user identifier uniquely identifies the user to the service application, and the service application identifier uniquely identifies the service application to the authenticator application. The binding may also include generating a device binding key pair. The device binding key pair includes a device public key and a device private key based on the user identifier and the service application identifier. The binding may also include signing the service application identifier using the device private key, and sending the device public key and the signed service application identifier to the remote entity.

[0011] In some embodiments, the method further includes binding, by an authenticator application running on the data processing hardware, a user account associated with the user and the remote entity to the user device. Binding may include signing a service application identifier using a device private key and sending the signed service application identifier to the service application running on the data processing hardware. When received by the service application, the signed service application identifier causes the service application to send the signed service application identifier and the account identifier to the remote entity. The account identifier uniquely identifies the user account.

[0012] In some examples, the method further includes, when the service application and the authenticator application are executed, executing one or more additional service applications by the data processing hardware. Each additional service application may be configured to receive a corresponding operation request, wherein the corresponding operation request requests the additional service application to access the same remote entity or a different remote entity to perform a corresponding operation. Each additional service application may also be configured to, before executing the operation on the same remote entity or a different remote entity, issue a corresponding authentication request, wherein the corresponding authentication request requests the authenticator application to obtain a user authentication credential of the user for authenticating the user, and is configured to receive an encrypted user authentication credential from the authenticator application to restrict the additional service application from obtaining the user authentication credential in an unencrypted form.

[0013] Another aspect of the present disclosure provides a system for authenticating operations within a consent architecture. The system includes data processing hardware of a user device running a service application and an authenticator application, and memory hardware in communication with the data processing hardware. The memory hardware stores instructions that, when executed on the data processing hardware, cause the data processing hardware to perform operations.

[0014] The operation includes obtaining an operation request requesting a service application to access a remote entity to perform an operation. The operation request includes a remote entity identifier that identifies the remote entity and operation information associated with the operation. The operation also includes an authentication request issued by the service application before the remote entity performs the operation, and the authentication request requests the authenticator application to obtain the user authentication credentials of the user of the user device associated with the remote entity for authenticating the user. The operation also includes the authenticator application encrypting the obtained user authentication credentials using the public key of the remote entity, thereby restricting the service application from obtaining the user authentication credentials in an unencrypted form. The operation also includes the authenticator application providing the encrypted user authentication credentials to the service application, and the service application transmitting the operation request and the encrypted user authentication credentials to the remote entity. When the operation request and the encrypted user authentication credentials are received by the remote entity, the remote entity uses the private key of the remote entity to decrypt the encrypted user authentication credentials and verify the decrypted user authentication credentials.

[0015] This aspect may include one or more of the following optional features. In some embodiments, the service application includes a payment application and the remote entity includes a financial institution associated with the user. The operation request requesting the service application to access the remote entity includes an electronic payment request requesting the payment application to initiate an electronic payment from the financial institution to a payee. In some examples, the operation information includes at least one of a description of the electronic payment, a value / amount of the electronic payment, at least a portion of a unique account identifier identifying an account associated with the user at the financial institution, or a payee identifier identifying the payee.

[0016] Optionally, the remote entity includes a record data store storing private information associated with the user, and the operation request requesting the service application to access the remote entity includes an information retrieval request requesting the service application to retrieve at least some of the private information from the record data store. The private information may include private records associated with the user. In some embodiments, the operation further includes, after encrypting the obtained user authentication credentials using the public key of the remote entity, re-encrypting, by the authenticator application, the encrypted user authentication credentials using a public key associated with the verification network of the remote entity.

[0017] In some examples, the operations further include, after encrypting the obtained user authentication credentials using the public key of the remote entity, signing the encrypted user authentication credentials by the authenticator application using the private key of the user device. The public key of the user device may be registered with the remote entity. The public key of the user device corresponds to the private key of the user device and is used by the remote entity to verify the signature of the encrypted user authentication credentials. Optionally, encrypting the obtained user authentication credentials using the public key of the remote entity also includes encrypting the operation request and the user authentication credentials together using the public key of the remote entity.

[0018] In some embodiments, the operation further includes, before encrypting the obtained user authentication credentials, issuing, by the authenticator application, a user device unlock challenge to the user. The authentication request issued by the service application may include an authorization token, which the authenticator application uses to authenticate the service application before obtaining the user authentication credentials.

[0019] Optionally, the operations further include: after transmitting the operation request and the encrypted user authentication credentials to the remote entity, receiving a challenge request from the remote entity at the service application. The challenge request requests additional user authentication credentials from the user. The operations may further include the service application calling the authenticator application to obtain the additional user authentication credentials from the user, and the authenticator application encrypting the obtained additional user authentication credentials using the public key of the remote entity. These operations may further include the authenticator application providing the encrypted additional user authentication credentials to the service application, and the service application transmitting a challenge response including the encrypted additional user authentication credentials to the remote entity. The challenge response, when received by the remote entity, causes the remote entity to decrypt the encrypted additional user authentication credentials using the private key of the remote entity and verify the decrypted additional user authentication credentials.

[0020] In some examples, the remote entity is configured to perform the operation based on the operation request after verifying both the decrypted user authentication credentials and the decrypted additional user authentication credentials.The remote entity can be configured to transfer the electronic payment to the payee after verifying the decrypted user authentication credentials.

[0021] In some examples, the operations further include binding, by the authenticator application, the identity of the user to the user device. The binding may include receiving a service registration request from the service application. The service registration request includes a user identifier and a service application identifier. The user identifier uniquely identifies the user to the service application, and the service application identifier uniquely identifies the service application to the authenticator application. Binding may also include generating a device-binding key pair. The device-binding key pair includes a device public key and a device private key based on the user identifier and the service application identifier. Binding may also include signing the service application identifier using the device private key, and sending the device public key and the signed service application identifier to the remote entity.

[0022] In some embodiments, the operations further include binding, via the authenticator application, a user account associated with the user and the remote entity to the user device. Binding may include signing a service application identifier using a device private key and sending the signed service application identifier to the service application. Upon receipt by the service application, the signed service application identifier causes the service application to send the signed service application identifier and the account identifier to the remote entity. The account identifier uniquely identifies the user account.

[0023] In some examples, the operations further include running one or more additional service applications while the service application and the authenticator application are running. Each additional service application may be configured to receive a corresponding operation request requesting the additional service application to access the same remote entity or a different remote entity to perform a corresponding operation. Each additional service application may also be configured to, before performing the operation on the same remote entity or a different remote entity, issue a corresponding authentication request requesting the authenticator application to obtain user authentication credentials of the user for authenticating the user, and to receive an encrypted user authentication credential from the authenticator application to restrict the additional service application from obtaining the user authentication credential in an unencrypted form.

[0024] The details of one or more embodiments of the disclosure are set forth in the accompanying drawings and the description below. Other aspects, features, and advantages will be apparent from the description and drawings, and from the claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] Figure 1 is a schematic diagram of an example authenticator of a consent architecture system for providing secure authentication from a user device to a remote entity.

[0026] Figure 2 Provides security authentication for payment applications Figure 1 Schematic diagram of the authenticator.

[0027] Figure 3 It is a schematic diagram of an operation request.

[0028] Figure 4is a diagram of a remote entity accessing a private data store.

[0029] Figure 5A and 5B is a schematic diagram of an example user device running a service application.

[0030] Figure 6 yes Figure 1 Schematic diagram of the authenticator application and service registration request.

[0031] Figure 7 is a diagram of an example user device that issues a challenge to the user to generate a device key pair.

[0032] Figure 8A and 8B is a schematic diagram of an example user device running a service application that provides account selection.

[0033] Figure 9 yes Figure 1 Diagram of the authenticator app and account registration request.

[0034] Figure 10 is a flow diagram of an example operational arrangement of a method for providing an authenticator application in a consent architecture.

[0035] Figure 11 is a schematic diagram of an example computing device that can be used to implement the systems and methods described herein.

[0036] Like reference numerals in the various drawings represent like elements. DETAILED DESCRIPTION

[0037] Service applications (such as those used to make real-time payments (RTP) or access sensitive information) will typically require user credentials to be provided to a remote entity that performs (or enables or participates in) the service requested by the user. Such credentials (such as username, PIN number, password, fingerprint data, etc.) are themselves sensitive information. If a malicious attacker is able to access such credentials via a malicious service application or via a legitimate service application with a security flaw / vulnerability, the attacker may be able to conduct unauthorized transactions or obtain unauthorized services not only in relation to that particular service application, but also in relation to other service applications that the user may use. For example, if an attacker is able to obtain a user's credentials via a security vulnerability in a service application running on a user's device that accesses personal health records, the attacker may also be able to use these credentials to conduct unauthorized financial transactions via a payment application installed on the user's device. If a second service application (over which the developer of the first service application has no control) is implemented in a less secure manner, the protections and security measures implemented by the first service application may be negated or rendered less effective.

[0038] With this in mind, the present invention provides an authenticator application that runs in conjunction with one or more service applications. As discussed in more detail later, the authenticator application can obtain a user's credentials in response to a request from a service application, encrypt those credentials (which are used to perform or provide the desired service associated with the requesting application) using the public key of the remote entity, and provide those encrypted credentials back to the service application. The service application itself does not obtain the user's credentials from the user. Therefore, the service application is blocked from accessing the user's credentials (because the service application does not have the private key of the remote entity required to decrypt the encrypted credentials). Therefore, an attacker cannot exploit a security vulnerability in a malicious service application or another service application to access and misuse the user's credentials.

[0039] Furthermore, the ability for multiple service applications to utilize the same authenticator application in this manner provides a variety of further technical benefits. In particular, the use of such an authenticator application allows security updates to be performed more quickly and easily—updating the authenticator application provides updated security for all service applications that use the authenticator application (rather than having to perform an update for each service application). Furthermore, memory on the user device is utilized more efficiently—the size of service applications is ultimately reduced because they no longer need to have their own functionality for obtaining the user's credentials via the device's user interface and then protecting those credentials. This benefit is enhanced as more and more service applications use the authenticator application.

[0040] Embodiments herein are directed to a system for providing a consent architecture that includes an authenticator application that provides secure authentication to a service application (e.g., a payment application) for use by a remote entity (e.g., a financial institution). Upon receiving an operation request from a service application, the authenticator application verifies that both the device and the user are authentic before providing encrypted authentication credentials to the service application. The service application then provides the encrypted credentials to the remote entity, which verifies the credentials. Thus, the service application never receives unencrypted credentials, and the user can provide some credentials to the authenticator application only once, regardless of the number of service applications used.

[0041] refer to Figure 1In some embodiments, the example system 100 includes a user device 10 associated with a corresponding user 12 and communicating with a remote authentication system 110 (also referred to herein as an authentication server), a remote service application system (also referred to herein as a service application server), and a remote entity system (also referred to herein as a remote entity) via a network 40. The user device 10 can correspond to any computing device, such as a desktop workstation, a laptop workstation, or a mobile device (i.e., a smartphone). The remote systems 110, 120, and 130 can be a single computer, multiple computers, or a distributed system (e.g., a cloud environment) with scalable / elastic computing resources (e.g., data processing hardware) and / or storage resources (e.g., memory hardware).

[0042] A user device 10 (e.g., a mobile phone) associated with user 12 may include associated memory hardware 20 and associated data processing hardware 30. User device 10 utilizes memory hardware 20 and data processing hardware 30 to store and run one or more service applications 140, 140a-n (also referred to as service apps). In some examples, service application 140 is a payment application that facilitates the real-time transfer of funds from a payer's account (i.e., user 12's user account) to a payee, as described in more detail below. Service application 140 may run as a standalone program on user device 10 or, for example, in a web browser. Service application 140 obtains, receives, and / or generates an operation request 142. Operation request 142 is typically created in response to a user action. For example, when service application 140 is a payment application, user 12 may initiate operation request 142 by attempting to transfer funds through the payment application. In some examples, service application 140 generates operation request 142 in response to a command from user 12. In other examples, the service application 140 communicates with the service application server 120 over the network 40 and the service application server 120 generates an operation request 142 and sends the operation request 142 to the service application 140 .

[0043] The operation request 142 includes a remote entity identifier 142a and additional operation information 142b associated with the operation. The remote entity identifier 142a identifies the remote entity 130 associated with the operation request 142. For example, the remote entity identifier 142a may be the name or other unique identifier of a financial institution that the user 12 has associated with the service application 140. The operation information 142b may include the information required to perform the operation ( Figure 3 ) For example, when the operation request 142 relates to a financial transaction, the operation information 142b may include a description of the financial payment, any value or amount associated with the payment, at least a portion of a unique identifier identifying an account of a user associated with the remote entity, and / or a payee identifier identifying a payee.

[0044] The user device 10 also runs an authenticator application 150. As used herein, the authenticator application 150 may also be referred to as an authenticator app, an authentication application, or an authentication app. The authenticator application 150 receives an authentication request 152 from the service application 140. The authentication request 152 requests the authenticator application 150 to obtain user authentication credentials 154 associated with the remote entity 130 in order to authenticate the user 12 before the remote entity 130 performs the operation 138 associated with the operation request 1402.

[0045] The user 12 provides user authentication credentials 154 of one or more remote entities 130 (e.g., financial institutions) to the authenticator application 150. That is, the user 12 provides the authenticator application 150 with the user authentication credentials 154 (e.g., user authentication credentials 154) necessary to access the user 12's account 137 at the remote entity 130. Figure 2 ). User 12 can provide separate user authentication credentials 154 for any number of remote entities 130. In other words, the user can "register" any number of user accounts for any number of remote entities 130 with authenticator application 150. User authentication credentials 154 can be a username and password, a personal identification number (PIN), a one-time password (OTP), a unique device key, or any other data that a remote entity 130 requires for authentication or cryptographic proof (i.e., a statement that can be cryptographically verified). In some examples, user 12 registers a single account from a remote entity 130 with authenticator application 150, while in other examples, user 12 registers all accounts associated with a remote entity 130 simultaneously.

[0046] In addition to receiving a user authentication credential 154 from the user 12 for the corresponding remote entity 130, the authenticator application 150 retrieves the public key 132 associated with the corresponding remote entity 130. The public key 132 constitutes one of the keys in a key pair used in public-key cryptography (also known as asymmetric cryptography). In public-key cryptography, a cryptographic algorithm generates a private key and a corresponding public key that form a one-way function such that data encrypted with the public key can only be decrypted with the associated private key. In this example, the remote entity 130 publicly provides its public key 132 and keeps the associated private key 133 hidden. Therefore, once the user authentication credential 154 is encrypted by the authenticator application 150 using the remote entity 130's public key 132, only the remote entity 130 (with the associated hidden private key 133) can decrypt the encrypted user authentication credential 154. In this way, the service application 140 is restricted from obtaining the unencrypted form of the user authentication credential 154.

[0047] In addition to encrypting user authentication credentials 154, authenticator application 150 optionally utilizes user authentication credentials 154 to encrypt additional information 155. For example, authenticator application 150 may encrypt additional transaction details (e.g., transaction amount, account identification, description, etc.) as well as other information such as a current timestamp and a unique identifier to form an encrypted packet 156. As discussed in more detail below, this additional information 155 may be used to provide additional authentication and verification of the operation.

[0048] Authenticator application 150 provides the encrypted user's packet 156 to service application 140. As previously described, service application 140 lacks the remote entity's private key 133 (i.e., the key associated with public key 132 used to encrypt user authentication credentials 154) and, therefore, cannot access the unencrypted user authentication credentials 154. Service application 140 transmits operation request 142 (now including encrypted packet 156) to remote entity 130. Remote entity 130 decrypts packet 156 (including encrypted user authentication credentials 154) from received operation request 142 using associated private key 133 using request decryptor 134, and verifies the decrypted user authentication credentials 154 using credential verifier 136.

[0049] Now refer to Figure 2 In some embodiments, system 100 includes a remote entity 130 including a financial institution 130F associated with user 12 and a service application 140 including a payment application 140P. In this case, operation request 142 is an electronic payment request 142P requesting payment application 140P to initiate an electronic payment from the financial institution to a payee. For example, user device 10 may launch payment application 140P to transfer funds to a payee. Payment application 140P typically requests operation information 142b, such as the identity of the payee, the transaction amount, and the account from which user 12 wishes to withdraw funds. Confirmation of payment from user 12 (e.g., user 12 pressing a "Confirm Payment" button 210) may initiate an authentication request 152 from payment application 140P to authenticator application 150.

[0050] The real-time payment network 220 (also referred to herein as a verification network) is maintained by some central authority (e.g., a national government) to facilitate interbank retail payments. That is, the RTP network can act as a bill clearinghouse and settle funds across issuers in a manner similar to a credit card network that handles the exchange and settlement of credit card operations. For example, India maintains the National Payment System of India, which includes a real-time payment service, which is a real-time interbank payment system. Similarly, Mexico operates Banxico to maintain instant payment services in Mexico. Typically, real-time payments must be verified and / or authenticated by the RTP network before the payment is approved. In some cases, the central authority (e.g., the government) does not provide the RTP network, but leaves all verification and authentication to individual financial institutions. The RTP network and / or financial institutions often provide access to the RTP network via an application programming interface (API). For example, some RTP networks provide a payment initiation service provider (PISP) ​​API.

[0051] Still refer to Figure 2 , a real-time payment network (RTP network) 220 can communicate with network 40. Payment application 140P can be a non-financial institution that accesses network 220 via an API and is capable of initiating payments. Payment application 140P, in some examples, is a standalone application and, in other examples, is executed in a web browser. In some embodiments, after receiving encrypted packet 156 from authenticator application 150, payment application 140P sends packet 156 and payment request 142P to payment application server 120P (or simply "payment server 120P"). Payment application server 120P is a computing entity that relays requests from payment application 140P to RTP network 220. Payment server 120P is typically authenticated by RTP network 220. That is, payment server 120P must prove to RTP network 220 that server 120P is a genuine server serving the approved payment application 140P. Once authenticated, payment server 120P forwards the received packet 156 and request 142P to RTP network 220.

[0052] As discussed in more detail below, the RTP network 220 can perform a set of verifications before approving a transaction. These verifications can be in addition to any verifications required by the financial institution 130F. To protect the RTP network operation, the authenticator application 150 can utilize the RTP network public key 222 to encrypt some or all of the user authentication credentials 154. Like the remote entity public key 132 (i.e., the public key of the financial institution 130F), the RTP network public key 222 can be one of a pair of keys used in public key cryptography, while the RTP network retains an associated secret network private key 224. In some embodiments, the network 220 has a separate master signing key 225 that is used to establish the authenticity of the RTP network 220. All data signed by this key can be verified using the corresponding master public key. For example, the authenticator application 150 can receive a Diffie-Hellman (DH) key signed by the master signing key 225 from the network 220, allowing the authenticator application 150 to verify the authenticity of the DH key. The master public key can be hard-coded into the authenticator application 150 because it may have a very long expiration time. Some or all of the user authentication credentials 154 may be encrypted using either or both of the remote entity key 132 and the network key 222. When the user authentication credentials 154 are encrypted using both, the RTP network 220 may decrypt the encrypted packet 156 using the network private key and then forward the packet 156 and the request 142P to the remote entity 130 so that the remote entity 130 may decrypt and access its portion of the packet 156.

[0053] After the financial institution 130F receives the payment request 142P from the RTP network 220, the payment application server 120P, or in some examples, directly from the payment application 140P, the financial institution 130F verifies any operation information 142b included in the operation request 142. For example, the financial institution 130F can verify that the operation information 142b from the operation request 142 (e.g., transaction amount, account identification, etc.) matches the additional information 155 encrypted by the authenticator application 150. In some examples, the financial institution 140F verifies that the phone number associated with the mobile device sending the request matches the phone number associated with the account being accessed. If the financial institution 140F desires (e.g., if the transaction is suspicious), the financial institution can issue one or more challenge requests 144 to the user 12 requesting additional user authentication credentials 154. Any challenge request 144 from the financial institution 130F may be forwarded back through the RTP network 220 to the payment server 120P, the payment application 140P, and ultimately back to the authenticator application 150, where the authenticator application 150 may obtain and encrypt the obtained additional user authentication credentials 154 from the user 12 to satisfy the challenge request 144 with a challenge response 157 ( Figure 2). Financial institution 140F can similarly decrypt the encrypted additional user authentication credentials 154 from challenge response 157 and verify that the decrypted additional user authentication credentials 154 satisfy challenge request 144. Once financial institution 130F accepts the transaction, the funds are transferred and financial institution 130F can transmit a confirmation back to RTP network 220, which in turn flows back to user 12 as notification 212. For example, payment application 140P can display a visual indication of success and / or play an audible message.

[0054] While in the context of the previous examples, the service application 140 is described as a payment application 140P and the remote entity 130 is described as a financial institution 130F, the authenticator application 150 is applicable to any situation where the user 12 is passing sensitive information to the remote entity via an untrusted third-party application. For example, the user 12 can initiate an information retrieval request 142R to obtain records from a private record data store (e.g., private records that the remote entity is obligated to keep confidential) or other private information associated with the user without exposing the user authentication credentials 154 in the clear. Referring now to Figure 4 In some embodiments, the authenticator application 150 encrypts the user authentication credentials 154 to enable access to a private record data store 410 storing private information 420 associated with the user 12. The private data store 410 may be an online repository of sensitive information (e.g., health records). After receiving the information retrieval request 142R from the service application 140, the remote entity 130 decrypts the encrypted package 156 at the request decryptor to obtain the decrypted credentials 154D and verifies the credentials at the credential verifier 136. After successful verification, the remote entity 130 retrieves one or more user records from the private record data store 410 storing the private information. The remote entity may return the retrieved records to the user 12 via the user device 10 or, if authorized, transfer the records to a third party. For example, the user 12 may authorize a private record company to transfer the private records to a facility that requires the records without the service application 140 knowing any information necessary to obtain the records (e.g., a social security number).

[0055] In some embodiments, the authenticator application 150, the service application 140, the network 220, and the remote entity 130 provide a secure environment by performing a standard set of verifications at each application step. For example, each time the authentication application 150 receives a request from the service application 140, the authenticator application 150 can verify the service application identification (ID) (i.e., an identification that uniquely identifies the service application 140) and / or an authorization certificate or some other form of authorization token 153 from the service application 140. Whenever the service application 140 communicates with the service application server 120, it can verify the server's certificate (e.g., via an x509 certificate signature). In some examples, the service application server 120 authenticates the service application user and authenticates to the network 220 using mutual Secure Sockets Layer (SSL) or Pretty Good Privacy (PGP) encryption as standard verification.

[0056] The network 220 can perform various checks whenever it receives a request from the service application server 120. For example, the network 220 can authenticate the service application server 120 using mutual SSL or PGP encryption. The network 220 can decrypt data from the authenticator application 150 using the network private encryption key 224. The network 220 can also verify the signature of any signed message from the authenticator application 150 (e.g., via the public key of the user device 10 ( Figure 6 )). In some embodiments, the network 220 ensures that the service application ID matches the ID provided by the service application server and ensures that any verification performed by the authenticator application 150 is recent by, for example, comparing a timestamp captured by the authenticator application 150 with the current time. The network 220 can invalidate any sufficiently old operation (e.g., to prevent replay attacks). Optionally, the network 220 maintains a whitelist of all service applications 140 and associated service application IDs that are authorized to access the consent architecture. The network 220 can maintain a repository of public keys of servers corresponding to the whitelisted service applications for proper server-to-server authentication.

[0057] In some embodiments, user 12 registers or initializes user device 10 and authenticator application 150 with service application 140 prior to use. This registration provides a strong binding between user device 10, user 12's digital identity (which can be shared with service application 140), and user 12's physical identity (which can be shared with remote entity 130 or network 220). In some examples, authenticator application 150 is a trusted application. That is, authenticator application 150 is trusted by network 220 and / or remote entity 130 to provide verified authentication of user information.

[0058] Now refer to Figure 5A, registration of the service application 140 typically begins via a request from the user 12 (e.g., via initiating user input 52 within the service application). The service application 140 collects various user information 504, such as name, phone number, unique identifier, and / or any other user information that the service application 140 desires for authentication ( Figure 5B In some examples, the service application 140 verifies the user information 504 with the service application server 120, while in other examples, the service application 140 has pre-verified the information. For example, some service applications 140 may have pre-verified the phone numbers of some users. For some applications, the service application 140 may collect identification or identification information that can be verified by, for example, querying a central database.

[0059] Now refer to Figure 6 After collecting and verifying the user information 94, the service application 140 calls the authenticator application 150 by sending a service registration request 602 including application registration information 604, 604a-c. The application registration information 604 provides data that the authenticator application 150 uses to verify and authenticate the registration. For example, the application registration information 604 may include a service application ID 604a, a user identifier (user ID) 604b that uniquely identifies the user 12 in the service application 140 namespace (i.e., no other user of the service application 140 has the same user ID), and a consent identification nonce 604c. The service application ID 604a can be used to verify that the service application 140 is an authorized application. The consent identification nonce 604c can be used to combat replay attacks. As described below, the authenticator application 150 uses the user ID 604b to generate a unique, user-specific key.

[0060] Authenticator application 150 receives service registration request 602 and can perform the standard verification set discussed above. Authenticator application 150 generates a unique device key pair 606, which is used to uniquely prove the identity of user device 10. The private key 606R of the key pair is stored in a secure element 615 within the device (e.g., within the memory hardware 20), and the corresponding device public key 606U is provided to the public (e.g., network 220 and / or remote entity 130). Secure element 616 ensures that any user or application of user device 10 cannot access private key 606R. Authenticator application 150 can use service application ID 604a, user ID 604b and unique device information (e.g., serial number, etc.) to generate device key 606. In this way, authenticator application 150 generates a unique device key 606 for each user of each service application 140.

[0061] Now refer to Figure 7In some examples, the use of private key 606R is protected by user challenge 704. For example, before user device 10 signs a message using private key 606R (i.e., to authenticate the message), user device 10 may prompt user 12 to enter a password or provide another identifier that can be used to authenticate the user. Thus, a message signed by device private key 606R inherently indicates both user and device authentication factors.

[0062] Return Reference Figure 6 In some embodiments, the authenticator application 150 uses the device private key 606R to sign the service registration response 608, which includes the service application identifier 604a, the consent random number 604c, and / or any certificates of the service application 140. Attestation by these keys can be provided by the operating system of the user device 10 to verify the integrity of the device and the strength and properties of the key 606. The authenticator application 150 returns the signed response 608 (including the signed service application identifier 604a) to the service application 140, which initiates a request to the service application server 120 ( Figure 1 ). In some examples, the service application server 120 initiates the registration request to the network 220, and in other examples, initiates the registration request to the remote entity 130. The service application server 120 sends the unique user ID 604b (or a unique derivative thereof, e.g., a hash value) to the network 220 (or remote entity 130), which uniquely identifies the user 12 to the service application 140. Other verification information (e.g., a phone number, a unique identifier, a device public key 606U, etc.) may also be sent.

[0063] Upon receiving the registration request, the network 220 or remote entity 130 may perform the standard set of verifications discussed above and verify the attributes of the device key 606R. In response to a successful verification, the network 220 or remote entity 130 creates a profile ID 610 that includes an association between the user 12, the service application 140, and the user device 10 (e.g., using the service application ID 604a, the user ID 604b, the verified phone number, the unique identifier, etc.) and sends the profile ID 610 back to the service application server 120, which stores the profile ID 610, thereby completing the user registration. The service application 140 may provide confirmation of the successful registration to the user 12. User registration allows the network 220 and / or remote entity 130 to reliably establish that the digital identity defined by the service application 140 has valid user application registration information 604 (e.g., the verified phone number), the user device 10, and consent to the registration. The service application server 120 has stored a profile ID associating the user 12 with the service application 140 and user application registration information 604. The authenticator application 150 has stored a generated device key 606 specific to the user 12 and the service application 140 that can be used as proof.

[0064] After the user registers with the service application 140, in some embodiments, the user 12 registers an account (or multiple accounts) with the remote entity 130 to establish a binding between the user device 10, the profile ID 610, and the associated accounts. Figure 8A , the user 12 creates an account registration request 902 (by providing a user input indication 802 (e.g., selecting a graphical element displayed on a graphical user interface running on the user device 10) Figure 9 The service application 140 can provide a valid organization list 804 ( Figure 8B ) for display on a graphical user interface for the user 12 to select from in response. List 804 can be periodically obtained from the service application server 120 or the network 220 and can include metadata such as names, logos, etc. List 804 can be cached on the memory hardware 20 of the user device 10 between periodic updates. The user 12 can use touch, a stylus, voice, gestures, or any other input mechanism to provide an input indication to select from the list 804 and / or provide an input indication 802 for initiating the account registration request 902.

[0065] Now refer to Figure 9In some embodiments, the service application 140 requests verification of device ownership from the authenticator application 150 by sending an account registration request 902 to the authenticator application 150. The account registration request 902 includes at least the user ID 604b. The authenticator application 150 may perform the standard verification described above, which establishes that the account binding request (i.e., the account registration request 902) originates from the same user device 10 that performed the associated user registration (see Figure 6 ). Authenticator application 150 (using Figure 6 The device key 606R shown signs the account registration response 908 including, for example, an identifier of the service application 140 and a current timestamp, thereby establishing a device possession factor. In some examples, the authenticator application 150 further provides the user ( Figure 7 ) issues a challenge 702 to establish knowledge or inherent second factor. A signed account registration response 908 is returned to the service application 140.

[0066] In some embodiments, the service application 140 requests the network 220 or remote entity 130 to list the associated accounts of the user 12 by sending a signed response 908, the profile ID 610, and the identification of the remote entity 130 (when sent to the network 220) via, for example, the service application server 120. The network 220 or remote entity 130 can perform its standard validation and verify any application registration information 604 (e.g., verified phone number, unique identifier, etc.). In some examples, the network 220 passes the request to list applicable accounts (i.e., accounts belonging to the user 12) along with any necessary identification data (e.g., phone number or unique identifier) ​​to the remote entity 130. The remote entity 130 can return the account list 910 to the service application server 120, whereupon the account list 910 is associated with the user based on the identification data. The account list 910 can include additional metadata 911, such as a name associated with the account, an account name, an account reference ID, and at least a portion of the unique account identifier (e.g., the last four digits of the account number). Optionally, the remote entity 130 can issue an additional challenge 920 at this time. For example, the remote entity 130 can request a one-time password (via Short Message Service (SMS), email, hardware-based, etc.), a password or personal identification number (PIN), specific account details, etc. In some embodiments, such a challenge is triggered if one factor matches, but a different factor does not match. For example, the user identification (e.g., unique identifier) ​​from an external database matches, but the phone number does not match. This may initiate a "yellow path" authentication (i.e., an authentication that requires additional verification). The challenge can be encrypted for additional security. For example, the challenge can be encrypted using a session key from a DH key exchange.

[0067] The service application server 120 relays the account list 910 to the service application 140 running on the user device 10 for display to the user 12. In some embodiments, the user 12 selects a specific account from the account list 910 associated with the user 12. In some embodiments, the user 12 selects all available accounts. The service application 140 can again verify device ownership from the authenticator application 150 and capture any data needed to satisfy the challenge from the remote entity 130. In this case, the service application 140 passes the user ID 604b and the signed remote entity encryption key to encrypt the challenge data. After performing any standard verification again, the authenticator application 150 challenges the user (e.g., requesting the user unlock the user device, enter a password, etc.) to confirm ownership and any challenge data issued from the remote entity. The authenticator application 150 encrypts any challenge results, the current timestamp, and the service application ID using the remote entity 130 key and signs the encrypted challenge response 930.

[0068] Authenticator application 150 passes the signed and encrypted response 930 to service application 140, which in turn passes it and a bind request 940 to service application server 120. Service application server 120 passes the data, along with profile ID 610, remote entity ID, and any necessary account ID 909 (i.e., an identifier that uniquely identifies the selected account), to network 220 or remote entity 130. Service application server 120 may also generate a correlation ID 912 to represent the account binding and also pass this ID 912 to network 220 / remote entity 130. Remote entity 130 (from network 220 or service application server 120) receives the bind request 940 and decrypts and verifies any challenge data. Remote entity 130 then stores 960 the binding between the selected account and the device public key 606U represented by the correlation ID. Remote entity 130 may record any details about any issued challenges to assist with authentication during transactions (e.g., yellow path, green path, etc.). The remote entity may store the device public key 606U so that the remote entity 130 can verify the device credentials before or during future transactions.

[0069] Thus, during account registration, the remote entity 130 stores a binding 960 between the remote entity account ID and the device public key 606U represented by the association ID 912. The authenticator application 150 has registered the key pair 606 representing this binding, and any future proof signed with the key pair's private key 606R provides proof of device ownership and an inherent second factor. The service application server 120 stores various data about the binding. For example, the service application server 120 may store the association ID, remote entity account metadata, profile ID 610, user ID 604b, and device ID. In this way, the authenticator application 150 securely communicates data to the network 220 and remote entity 130 while ensuring that the network 220 and remote entity 130 can verify that any data was captured on the device registered during user registration.

[0070] Figure 10 138. FIGURE 1 is a flow diagram of an exemplary operational arrangement of a method 1000 for authenticating operations within a consent architecture. The method 1000 begins at operation 1002, where, at the data processing hardware 30 of a user device 10 running a service application 140 and an authenticator application 150, an operation request 142 is obtained, requesting the service application 140 to access a remote entity 130 to perform an operation 138. The operation request 142 includes a remote entity identifier 142a identifying the remote entity 130 and operation information 142b associated with the operation 138. At operation 1004, the method 1000 includes, before the remote entity 130 performs the operation 138, issuing an authentication request 152 by the service application 140 running on the data processing hardware 30, requesting the authenticator application 150 to obtain user authentication credentials 154 of a user 12 of the user device 10 associated with the remote entity 130 for use in authenticating the user 12.

[0071] At operation 1006, method 1000 includes encrypting, by the authenticator application 150 running on the data processing hardware 30, the obtained user authentication credentials 154 using the public key 132 of the remote entity 130. The service application 140 is restricted from obtaining the user authentication credentials 154 in an unencrypted form. At operation 1008, method 1000 also includes providing, by the authenticator application 150 running on the data processing hardware 30, the encrypted user authentication credentials 154 to the service application 140, and at operation 1010, method 1000 includes sending, by the service application 140 running on the data processing hardware 30, an operation request 142 to the remote entity 130. The operation request 142 includes the encrypted user authentication credentials 154. When received by the remote entity 130, the operation request 142 causes the remote entity 130 to decrypt the encrypted user authentication credentials 154 using the private key 133 of the remote entity 130 and verify the decrypted user authentication credentials 154.

[0072] Figure 11is a schematic diagram of an example computing device 1100 that can be used to implement the systems and methods described in this document. Computing device 1100 is intended to represent various forms of digital computers, such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers. The components shown here, their connections and relationships, and their functions are exemplary only and are not meant to limit implementations of the inventions described and / or claimed in this document.

[0073] Computing device 1100 includes a processor 1110, memory 1120, storage device 1130, a high-speed interface / controller 1140 connected to memory 1120 and a high-speed expansion port 1150, and a low-speed interface / controller 1160 connected to a low-speed bus 1170 and storage device 1130. Each of components 1110, 1120, 1130, 1140, 1150, and 1160 is interconnected using various buses and can be mounted on a common motherboard or otherwise installed as appropriate. Processor 1110 is capable of processing instructions for execution within computing device 1100, including instructions stored in memory 1120 or on storage device 1130, to display graphical information for a graphical user interface (GUI) on an external input / output device such as a display 1180 coupled to high-speed interface / controller 1140. In other embodiments, multiple processors and / or multiple buses, as well as multiple memories and memory types, can be used as appropriate. Furthermore, multiple computing devices 1100 may be connected, with each device providing portions of the necessary operations (eg, as a server bank, a blade server bank, or a multi-processor system).

[0074] The memory 1120 stores information non-transitorily within the computing device 1100. The memory 1120 may be a computer-readable medium, a volatile memory unit, or a non-volatile memory unit. The non-transitory memory 1120 may be a physical device used to store programs (e.g., instruction sequences) or data (e.g., program state information) on a temporary or permanent basis for use by the computing device 1100. Examples of non-volatile memory include, but are not limited to, flash memory and read-only memory (ROM) / programmable read-only memory (PROM) / erasable programmable read-only memory (EPROM) / electrically erasable programmable read-only memory (EEPROM) (e.g., commonly used for firmware, such as bootloaders). Examples of volatile memory include, but are not limited to, random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), phase change memory (PCM), and disk or tape.

[0075] The storage device 1130 can provide mass storage for the computing device 1100. In some embodiments, the storage device 1130 is a computer-readable medium. In various embodiments, the storage device 1130 can be a floppy disk device, a hard disk device, an optical disk device, or a magnetic tape device, a flash memory or other similar solid-state storage device or device array (including devices in a storage area network or other configurations). In another embodiment, a computer program product is tangibly embodied in an information carrier. The computer program product includes instructions for executing one or more methods at runtime, such as those described above. The information carrier is a computer or machine-readable medium, such as the memory 1120, the storage device 1130, or the memory on the processor 1110.

[0076] The high-speed interface / controller 1140 manages bandwidth-intensive operations of the computing device 1100, while the low-speed controller 1160 manages less bandwidth-intensive operations. This division of responsibilities is exemplary only. In some embodiments, the high-speed interface / controller 1140 is coupled to the memory 1120, the display 1180 (e.g., via a graphics processor or accelerator), and to the high-speed expansion ports 1150 that can accept various expansion cards (not shown). In some embodiments, the low-speed controller 1160 is coupled to the storage device 1130 and the low-speed expansion ports 1190. The low-speed expansion ports 1190, which can include various communication ports (e.g., USB, Bluetooth, Ethernet, wireless Ethernet), can be coupled to one or more input / output devices, such as a keyboard, pointing device, scanner, or networking equipment, such as a switch or router, for example, via a network adapter.

[0077] As shown, computing device 1100 can be implemented in a variety of different forms. For example, it can be implemented as a standard server 1100a or multiple implementations in a group of such servers 1100a, implemented as a laptop computer 1100b, or implemented as part of a rack server system 1100c.

[0078] Various embodiments of the systems and techniques described herein can be implemented in digital electronic and / or optical circuitry, integrated circuits, specially designed ASICs (application-specific integrated circuits), computer hardware, firmware, software, and / or combinations thereof. These various embodiments can include implementations in one or more computer programs that are executable and / or interpretable on a programmable system that includes at least one programmable processor, which can be special purpose or general purpose, coupled to receive data and instructions from and transmit data and instructions to a storage system, at least one input device, and at least one output device.

[0079] A software application (i.e., a software resource) may refer to computer software that enables a computing device to perform tasks. In some examples, a software application may be referred to as an "application," "app," or "program." Example applications include, but are not limited to, system diagnostic applications, system management applications, system maintenance applications, word processing applications, spreadsheet applications, messaging applications, media streaming applications, social networking applications, and gaming applications.

[0080] These computer programs (also referred to as programs, software, software applications, or code) include machine instructions for a programmable processor and can be implemented in high-level procedural and / or object-oriented programming languages ​​and / or in assembly / machine language. As used herein, the terms "machine-readable medium" and "computer-readable medium" refer to any computer program product, non-transitory computer-readable medium, apparatus, and / or device (e.g., a magnetic disk, optical disk, memory, programmable logic device (PLD)) for providing machine instructions and / or data to a programmable processor, including machine-readable media that receive machine instructions as a machine-readable signal. The term "machine-readable signal" refers to any signal used to provide machine instructions and / or data to a programmable processor.

[0081] The processes and logic flows described in this specification can be performed by one or more programmable processors, also referred to as data processing hardware, that run one or more computer programs to perform functions by operating on input data and generating output. The processes and logic flows can also be performed by dedicated logic circuits, such as FPGAs (field programmable gate arrays) or ASICs (application-specific integrated circuits). Processors suitable for running computer programs include, for example, general-purpose and special-purpose microprocessors and any one or more processors of any type of digital computer. Typically, a processor will receive instructions and data from a read-only memory or a random access memory, or both. The basic elements of a computer are a processor for executing instructions and one or more storage devices for storing instructions and data. Typically, a computer will also include one or more mass storage devices for storing data, such as magnetic, magneto-optical disks, or optical disks, or be operably coupled to receive data from or send data to, or both, the one or more mass storage devices for storing data, such as magnetic, magneto-optical disks, or optical disks. However, a computer need not necessarily have such devices. Computer-readable media suitable for storing computer program instructions and data include all forms of nonvolatile memory, media, and storage devices, including, for example: semiconductor memory devices, such as EPROM, EEPROM, and flash memory devices; magnetic disks, such as internal hard disks or removable disks; magneto-optical disks; and CD ROM and DVD-ROM disks. The processor and memory can be supplemented by, or incorporated in, special purpose logic circuitry.

[0082] To provide for interaction with a user, one or more aspects of the present disclosure can be implemented on a computer having a display device, such as a CRT (cathode ray tube), LCD (liquid crystal display) monitor, or a touch screen for displaying information to the user, and an optional keyboard and pointing device, such as a mouse or trackball, through which the user can provide input to the computer. Other types of devices can also be used to provide for interaction with the user; for example, feedback provided to the user can be any form of sensory feedback, such as visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form including sound, voice, or tactile input. In addition, the computer can interact with the user by sending documents to and receiving documents from a device used by the user; for example, by sending a web page to a web browser on a user's client device in response to a request received from the web browser.

[0083] A number of embodiments have been described. However, it will be understood that various modifications can be made without departing from the spirit and scope of this disclosure. Accordingly, other embodiments are within the scope of the following claims.

Claims

1. A method (1000) for authenticating operations within a consent framework, comprising: An operation request (142) is obtained at data processing hardware (30) of a user device (10) running a service application (140) and an authenticator application (150), the operation request (142) being used to request the service application (140) to access a remote entity (130) to perform an operation (138), the operation request (142) comprising: a remote entity identifier (142a) identifying the remote entity (130); and Operation information (142b) associated with the operation (138); Before the remote entity (130) performs the operation (138), the service application (140) running on the data processing hardware (30) issues an authentication request (152), the authentication request (152) being used to request the authenticator application (150) to obtain user authentication credentials (154) of a user (12) of the user device (10) associated with the remote entity (130) for authenticating the user (12); encrypting, by the authenticator application (150) running on the data processing hardware (30), the obtained user authentication credentials (154) using the public key (132) of the remote entity (130), such that the service application (140) is restricted from obtaining the user authentication credentials (154) in an unencrypted form; providing the encrypted user authentication credentials (154) to the service application (140) by the authenticator application (150) running on the data processing hardware (30); and The service application (140) running on the data processing hardware (30) transmits the operation request (142) and the encrypted user authentication credential (154) to the remote entity (130), the operation request (142) and the encrypted user authentication credential (154) when received by the remote entity (130) causing the remote entity (130) to: decrypting the encrypted user authentication credentials (154) using the remote entity's (130) private key (133); and The decrypted user authentication credentials are verified (154).

2. The method (1000) of claim 1, wherein: The service application (140) includes a payment application (140P); The remote entity (130) includes a financial institution (130F) associated with the user (12); as well as The operation request (142) for requesting the service application (140) to access the remote entity (130) includes an electronic payment request (142P) for requesting the payment application (140P) to initiate an electronic payment from the financial institution (130F) to a payee.

3. The method (1000) according to claim 2, wherein: The operational information (142b) includes at least one of: a description of the electronic payment, a value / amount of the electronic payment, at least a portion of a unique account identifier identifying an account associated with the user (12) at the financial institution (130F), or a payee identifier identifying the payee.

4. The method (1000) of claim 1, wherein: The remote entity (130) includes a record data store (410) storing private information (420) associated with the user (12); and The operation request (142) for requesting the service application (140) to access the remote entity (130) includes an information retrieval request (142R) for requesting the service application (140) to retrieve at least some of the private information (420) from the record data storage (410).

5. The method (1000) according to claim 4, wherein: The private information (420) includes private records associated with the user (12).

6. The method (1000) of claim 1, further comprising: After the obtained user authentication credentials (154) are encrypted using the public key (132) of the remote entity (130), the encrypted user authentication credentials (154) are re-encrypted by the authenticator application (150) running on the data processing hardware (30) using the public key (222) associated with the verification network (220) of the remote entity (130).

7. The method (1000) of claim 1, further comprising: After the obtained user authentication credential (154) is encrypted using the public key (132) of the remote entity (130), the encrypted user authentication credential (154) is signed by the authenticator application (150) running on the data processing hardware (30) using the private key (606R) of the user device (10).

8. The method (1000) according to claim 7, wherein: The public key (606U) of the user device (10) is registered with the remote entity (130), the public key (606U) of the user device (10) corresponds to the private key (606R) of the user device (10) and is used by the remote entity (130) to verify the signature of the encrypted user authentication credential (154).

9. The method (1000) of claim 1, wherein: Encrypting the obtained user authentication credentials (154) using the public key (132) of the remote entity (130) also includes encrypting the operation request (142) and the user authentication credentials (154) together using the public key (132) of the remote entity (130).

10. The method (1000) of claim 1, further comprising: Prior to encrypting the obtained user authentication credentials (154), the authenticator application (150) running on the data processing hardware (30) issues a user device (10) unlock challenge to the user (12).

11. The method (1000) of claim 1, wherein: The authentication request (152) issued by the service application (140) includes an authorization token (153), which the authenticator application (150) uses to verify the service application (140) before obtaining the user authentication credentials (154).

12. The method (1000) according to any one of claims 1 to 11, further comprising: After transmitting the operation request (142) and the encrypted user authentication credentials (154) to the remote entity (130): receiving, at the service application (140) running on the data processing hardware (30), a challenge request (144) from the remote entity (130), the challenge request (144) requesting additional user authentication credentials (154) from the user (12); calling, by the service application (140) running on the data processing hardware (30), the authenticator application (150) to obtain the additional user authentication credentials (154) from the user (12); encrypting, by the authenticator application (150) running on the data processing hardware (30), the obtained additional user authentication credentials (154) using the public key (132) of the remote entity (130); providing the encrypted additional user authentication credentials (154) to the service application (140) by the authenticator application (150) running on the data processing hardware (30); as well as transmitting, by the service application (140) running on the data processing hardware (30), to the remote entity (130), a challenge response (157) including the encrypted additional user authentication credentials (154), the challenge response (157) when received by the remote entity (130) causing the remote entity (130) to: decrypting the encrypted additional user authentication credentials (154) using the private key (133) of the remote entity (130); and The decrypted additional user authentication credentials are verified (154).

13. The method (1000) according to claim 12, wherein: The remote entity (130) is configured to perform an operation (138) based on the operation request (142) after verifying both the decrypted user authentication credentials (154) and the decrypted additional user authentication credentials (154).

14. The method (1000) of claim 12, wherein: The remote entity (130) is configured to transfer the electronic payment to the payee after verifying the decrypted user authentication credentials (154).

15. The method (1000) according to any one of claims 1-11, further comprising: The authenticator application (150) running on the data processing hardware (30) binds the identity of the user (12) to the user device (10), the binding comprising: receiving a service registration request (602) from the service application (140) running on the data processing hardware (30), the service registration request (602) including a user identification (604b) and a service application identification (604a), the user identification (604b) uniquely identifying the user (12) to the service application (140), and the service application identification (604a) uniquely identifying the service application (140) to the authenticator application (150); Generate a device binding key pair (606), the device binding key pair (606) including a device public key (606U) and a device private key (606R) based on the user identifier (604b) and the service application identifier (604a); Signing the service application identifier (604a) using the device private key (606R); and The device public key (606U) and the signed service application identification (604a) are sent to the remote entity (130).

16. The method (1000) of claim 15, further comprising: Binding a user account (137) associated with the user (12) and the remote entity (130) to the user device (10) by the authenticator application (150) running on the data processing hardware (30), the binding comprising: Signing the service application identifier (604a) using the device private key (606R); and The signed service application identification (604a) is sent to the service application (140) running on the data processing hardware (30), and the signed service application identification (604a) when received by the service application (140) causes the service application (140) to send the signed service application identification (604a) and the account identification (909) to the remote entity (130), wherein the account identification (909) uniquely identifies the user account (137).

17. The method (1000) according to any one of claims 1 to 11, further comprising, when running the service application (140) and the authenticator application (150): One or more additional service applications (140) are run by the data processing hardware (30), each additional service application (140) being configured to: receiving a corresponding operation request (142), the corresponding operation request (142) being used to request the additional service application (140) to access the same remote entity (130) or a different remote entity (130) to perform a corresponding operation (138); Before the same remote entity (130) or a different remote entity (130) performs the operation (138), issuing a corresponding authentication request (152) for requesting the authenticator application (150) to obtain the user authentication credential (154) of the user (12) for use in authenticating the user (12); and An encrypted user authentication credential (154) is received from the authenticator application (150) to restrict the additional service application (140) from obtaining the user authentication credential (154) in an unencrypted form.

18. A system (100) for authenticating operations within a consent framework, comprising: Data processing hardware (30) of the user device (10), the data processing hardware (30) running the service application (140) and the authenticator application (150); and Memory hardware (20) in communication with the data processing hardware (30), the memory hardware (20) storing instructions that, when executed on the data processing hardware (30), cause the data processing hardware (30) to perform operations comprising: Obtaining an operation request (142), wherein the operation request (142) is used to request the service application (140) to access a remote entity (130) to perform an operation (138), wherein the operation request (142) includes: a remote entity identifier (142a) identifying the remote entity (130); and Operation information (142b) associated with the operation (138); Before the remote entity (130) performs the operation (138), the service application (140) issues an authentication request (152), the authentication request (152) being used to request the authenticator application (150) to obtain user authentication credentials (154) of a user (12) of the user device (10) associated with the remote entity (130) for authenticating the user (12); encrypting, by the authenticator application (150), the obtained user authentication credentials (154) using the public key (132) of the remote entity (130), such that the service application (140) is restricted from obtaining the user authentication credentials (154) in unencrypted form; providing, by the authenticator application (150), the encrypted user authentication credentials (154) to the service application (140); and The operation request (142) and the encrypted user authentication credentials (154) are transmitted by the service application (140) to the remote entity (130), the operation request (142) and the encrypted user authentication credentials (154) when received by the remote entity (130) causing the remote entity (130) to: decrypting the encrypted user authentication credentials (154) using the remote entity's (130) private key (133); and The decrypted user authentication credentials are verified (154).

19. The system (100) of claim 18, wherein: The service application (140) includes a payment application (140P); The remote entity (130) includes a financial institution (130F) associated with the user (12); as well as The operation request (142) for requesting the service application (140) to access the remote entity (130) includes an electronic payment request (142P) for requesting the payment application (140P) to initiate an electronic payment from the financial institution (130F) to a payee.

20. The system (100) of claim 19, wherein: The operational information (142b) includes at least one of: a description of the electronic payment, a value / amount of the electronic payment, at least a portion of a unique account identifier identifying an account associated with the user (12) at the financial institution (130F), or a payee identifier identifying the payee.

21. The system (100) of claim 18, wherein: The remote entity (130) includes a record data store (410) storing private information (420) associated with the user (12); and The operation request (142) for requesting the service application (140) to access the remote entity (130) includes an information retrieval request (142R) for requesting the service application (140) to retrieve at least some of the private information (420) from the record data storage (410).

22. The system (100) of claim 21, wherein: The private information (420) includes private records associated with the user (12).

23. The system (100) of claim 18, further comprising: After encrypting the obtained user authentication credentials (154) using the public key (132) of the remote entity (130), the encrypted user authentication credentials (154) are re-encrypted by the authenticator application (150) using a public key (222) associated with the verification network (220) of the remote entity (130).

24. The system (100) of claim 18, further comprising: After encrypting the obtained user authentication credential (154) using the public key (132) of the remote entity (130), the encrypted user authentication credential (154) is signed by the authenticator application (150) using the private key (606R) of the user device (10).

25. The system (100) of claim 24, wherein: The public key (606U) of the user device (10) is registered with the remote entity (130), the public key (606U) of the user device (10) corresponds to the private key (606R) of the user device (10) and is used by the remote entity (130) to verify the signature of the encrypted user authentication credential (154).

26. The system (100) of claim 18, wherein: Encrypting the obtained user authentication credentials (154) using the public key (132) of the remote entity (130) also includes encrypting the operation request (142) and the user authentication credentials (154) together using the public key (132) of the remote entity (130).

27. The system (100) of claim 18, further comprising: Before encrypting the obtained user authentication credentials (154), the authenticator application (150) issues a user device (10) unlock challenge to the user (12).

28. The system (100) of claim 18, wherein: The authentication request (152) issued by the service application (140) includes an authorization token (153), which the authenticator application (150) uses to verify the service application (140) before obtaining the user authentication credentials (154).

29. The system (100) according to any one of claims 18-28, wherein The operations further include, after transmitting the operation request (142) and the encrypted user authentication credentials (154) to the remote entity (130): receiving, at the service application (140), a challenge request (144) from the remote entity (130), the challenge request (144) requesting additional user authentication credentials (154) from the user (12); calling, by the service application (140), the authenticator application (150) to obtain the additional user authentication credentials (154) from the user (12); encrypting, by the authenticator application (150), the obtained additional user authentication credentials (154) using the public key (132) of the remote entity (130); providing, by the authenticator application (150), the encrypted additional user authentication credentials (154) to the service application (140); as well as transmitting, by the service application (140) to the remote entity (130), a challenge response (157) including the encrypted additional user authentication credentials (154), the challenge response (157) when received by the remote entity (130) causing the remote entity (130) to: decrypting the encrypted additional user authentication credentials (154) using the private key (133) of the remote entity (130); and The decrypted additional user authentication credentials are verified (154).

30. The system (100) of claim 29, wherein: The remote entity (130) is configured to perform an operation (138) based on the operation request (142) after verifying both the decrypted user authentication credentials (154) and the decrypted additional user authentication credentials (154).

31. The system (100) of claim 28, wherein: The remote entity (130) is configured to transfer the electronic payment to the payee after verifying the decrypted user authentication credentials (154).

32. The system (100) according to any one of claims 18-28, further comprising: The authenticator application (150) binds the identity of the user (12) to the user device (10), the binding comprising: receiving a service registration request (602) from the service application (140), the service registration request (602) including a user identification (604b) and a service application identification (604a), the user identification (604b) uniquely identifying the user (12) to the service application (140), and the service application identification (604a) uniquely identifying the service application (140) to the authenticator application (150); Generate a device binding key pair (606), the device binding key pair (606) including a device public key (606U) and a device private key (606R) based on the user identifier (604b) and the service application identifier (604a); Signing the service application identifier (604a) using the device private key (606R); and The device public key (606U) and the signed service application identification (604a) are sent to the remote entity (130).

33. The system (100) of claim 32, further comprising: Binding, by the authenticator application (150), a user account (137) associated with the user (12) and the remote entity (130) to the user device (10), the binding comprising: Signing the service application identifier (604a) using the device private key (606R); and The signed service application identification (604a) is sent to the service application (140), and the signed service application identification (604a) when received by the service application (140) causes the service application (140) to send the signed service application identification (604a) and an account identification (909) to the remote entity (130), the account identification (909) uniquely identifying the user account (137).

34. The system (100) according to any one of claims 18-28, wherein The operations further include, when running the service application (140) and the authenticator application (150): One or more additional service applications (140) are run, each additional service application (140) being configured to: receiving a corresponding operation request (142), the corresponding operation request (142) being used to request the additional service application (140) to access the same remote entity (130) or a different remote entity (130) to perform a corresponding operation (138); Before the same remote entity (130) or a different remote entity (130) performs the operation (138), issuing a corresponding authentication request (152) for requesting the authenticator application (150) to obtain the user authentication credential (154) of the user (12) for use in authenticating the user (12); and An encrypted user authentication credential (154) is received from the authenticator application (150) to restrict the additional service application (140) from obtaining the user authentication credential (154) in an unencrypted form.

Images