Patent Description:
Real time payments (RTPs) are financial transactions that allow payees to receive payment within seconds (i.e., in "real time") of the sending financial institution initiating the transaction. These payment systems are often maintained by an RTP network, which is typically a central authority that facilitates money across issuers similarly to credit card networks that handle interchange and settlements. RTPs are often conducted via user devices (e.g., mobile phones) executing payment applications (apps) to instantly transfer money from one user's account at a financial institution to another user's account at a different or same financial institution. These payment apps usually gain access to the RTP network via application programming interfaces (APIs). RTPs have greatly increased in popularly, and as the number of transactions has soared, the number of competing payment applications has likewise increased. It is not unusual for a user to have multiple independent payment apps on the same user device, each payment app authorized to access one or more of the user's accounts. Document <CIT> describes a method of processing a remote transaction initiated by a mobile device comprising a server computer receiving a payment request including encrypted payment information, the encrypted payment information being generated by a mobile payment application of the mobile device and being encrypted using a third party key; the method further comprises decrypting the encrypted payment information using the third party key, determining a transaction processor public key associated with the payment information, and re-encrypting the payment information using the transaction processor public key; the method further comprises sending a payment response including the re-encrypted payment information to a transaction processor; the transaction processor decrypts the re-encrypted payment information using a transaction processor private key and initiates a payment transaction. Document <CIT> describes another method of processing a remote transaction initiated by a mobile device.

One aspect of the disclosure provides a method of authenticating operations within consent architecture. The method includes obtaining, at data processing hardware of a user device executing a service application and an authenticator application, an 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 issuing, by the service application executing on the data processing hardware, an authentication request requesting the authenticator application to obtain user authentication credentials of a user of the user device associated with the remote entity for authenticating the user before the remote entity performs the operation. The method also includes encrypting, by the authenticator application executing on the data processing hardware, the obtained user authentication credentials using a public key of the remote entity so that the service application is restricted from obtaining the user authentication credentials in unencrypted form. The method also includes providing, by the authenticator application executing on the data processing hardware, the encrypted user authentication credentials to the service application and transmitting, by the service application executing on the data processing hardware, to the remote entity, the operation request and the encrypted user authentication credentials. The operation request and the encrypted user authentication credentials when received by the remote entity causes the remote entity to decrypt the encrypted user authentication credentials using a private key of the remote entity and validate the decrypted user authentication credentials.

Implementations of the 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.

Optionally, the remote entity includes a records datastore 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 records datastore. 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 is information for which a service provider has obligations to keep confidential. In some implementations, the method further includes, after encrypting the obtained user authentication credentials using the public key of the remote entity, re-encrypting, by the authenticator application executing on the data processing hardware, the encrypted user authentication credentials using a public key associated with a verification network of the remote entity.

In some examples, the method further includes, after encrypting the obtained user authentication credentials using the public key of the remote entity, signing, by the authenticator application executing on the data processing hardware, the encrypted user authentication credentials using a private key of the user device. A 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 further includes encrypting the operation request and the user authentication credentials together using the public key of the remote entity.

In some implementations, the method further includes, prior to encrypting the obtained user authentication credentials, issuing, by the authenticator application executing 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 that the authenticator application uses to validate the service application prior to obtaining the user authentication credentials.

Optionally, the method further includes, after transmitting the operation request and the encrypted user authentication credentials to the remote entity, receiving, at the service application executing on the data processing hardware, a challenge request from the remote entity. The challenge request requests additional user authentication credentials from the user. The method may also include invoking, by the service application executing on the data processing hardware, the authenticator application to obtain the additional user authentication credentials from the user and encrypting, by the authenticator application executing on the data processing hardware, the obtained additional user authentication credentials using the public key of the remote entity. The method may also include providing, by the authenticator application executing on the data processing hardware, the encrypted additional user authentication credentials to the service application and transmitting, by the service application executing on the data processing hardware, 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 validate the decrypted additional user authentication credentials.

In some examples, the remote entity is configured to perform an operation based on the operation request after validating both the decrypted user authentication credentials and the decrypted additional user authentication credentials. The remote entity may be configured to transfer an electronic payment to a payee after validating the decrypted user authentication credentials.

In some examples, the method further includes binding, by the authenticator application executing on the data processing hardware, an identity of the user to the user device. The binding may include receiving a service registration request from the service application executing on the data processing hardware. The service registration request includes a user identification and a service application identification. The user identification uniquely identifies the user to the service application and the service application identification s uniquely identifies the service application to the authenticator application. The binding may also include generating a device bound key pair. The device bound key pair includes a device public key and a device private key based on the user identification and the service application identification. The binding may also include signing the service application identification with the device private key and sending the device public key and the signed service application identification to the remote entity.

In some implementations, the method further includes binding, by the authenticator application executing on the data processing hardware, a user account associated with the user and the remote entity with the user device. The binding may include signing the service application identification with the device private key and sending the signed service application identification a to the service application executing on the data processing hardware. The signed service application identification when received by the service application causes the service application to send the signed service application identification and an account identification to the remote entity. The account identification uniquely identifying the user account.

In some examples, the method further includes, when executing the service application and the authenticator application, executing, by the data processing hardware, one or more additional service applications. 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 issue a corresponding authentication request requesting the authenticator application to obtain the user authentication credentials of the user for authenticating the user before the same remote entity or a different remote entity performs the operation and receive the encrypted user authentication credentials from the authenticator application so as to restrict the additional service application from obtaining the user authentication credentials in unencrypted form.

Another aspect of the disclosure provides a system for authenticating operations within consent architecture. The system includes data processing hardware of a user device executing 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.

The operations include obtaining an 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 operations also include issuing, by the service application, an authentication request requesting the authenticator application to obtain user authentication credentials of a user of the user device associated with the remote entity for authenticating the user before the remote entity performs the operation. The operations also include encrypting, by the authenticator application, the obtained user authentication credentials using a public key of the remote entity so that the service application is restricted from obtaining the user authentication credentials in unencrypted form. The operations also include providing, by the authenticator application, the encrypted user authentication credentials to the service application and transmitting, by the service application, to the remote entity, the operation request and the encrypted user authentication credentials. The operation request and the encrypted user authentication credentials when received by the remote entity causes the remote entity to decrypt the encrypted user authentication credentials using a private key of the remote entity and validate the decrypted user authentication credentials.

This aspect 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.

Optionally, the remote entity includes a records datastore 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 records datastore. The private information may include private records associated with the user. In some implementations, the operations further include, 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 a verification network of the remote entity.

In some examples, the operations further include, after encrypting the obtained user authentication credentials using the public key of the remote entity, signing, by the authenticator application, the encrypted user authentication credentials using a private key of the user device. A 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 further includes encrypting the operation request and the user authentication credentials together using the public key of the remote entity.

In some implementations, the operations further include, prior to 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 that the authenticator application uses to validate the service application prior to obtaining the user authentication credentials.

Optionally, the operations further include, after transmitting the operation request and the encrypted user authentication credentials to the remote entity, receiving, at the service application, a challenge request from the remote entity. The challenge request requests additional user authentication credentials from the user. The operations may also include invoking, by the service application, the authenticator application to obtain the additional user authentication credentials from the user and encrypting, by the authenticator application, the obtained additional user authentication credentials using the public key of the remote entity. The operations may also include providing, by the authenticator application, the encrypted additional user authentication credentials to the service application and transmitting, by the service application, 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 validate the decrypted additional user authentication credentials.

In some examples, the operations further includes binding, by the authenticator application, an 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 identification and a service application identification. The user identification uniquely identifies the user to the service application and the service application identification s uniquely identifies the service application to the authenticator application. The binding may also include generating a device bound key pair. The device bound key pair includes a device public key and a device private key based on the user identification and the service application identification. The binding may also include signing the service application identification with the device private key and sending the device public key and the signed service application identification to the remote entity.

In some implementations, the operations further includes binding, by the authenticator application, a user account associated with the user and the remote entity with the user device. The binding may include signing the service application identification with the device private key and sending the signed service application identification a to the service application. The signed service application identification when received by the service application causes the service application to send the signed service application identification and an account identification to the remote entity. The account identification uniquely identifying the user account.

In some examples, the operations further include, when executing the service application and the authenticator application, executing one or more additional service applications. 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 issue a corresponding authentication request requesting the authenticator application to obtain the user authentication credentials of the user for authenticating the user before the same remote entity or a different remote entity performs the operation and receive the encrypted user authentication credentials from the authenticator application so as to restrict the additional service application from obtaining the user authentication credentials in unencrypted form.

Service applications (such as applications for conducting real time payments (RTPs) or accessing sensitive information) will often need to provide user credentials to a remote entity that performs (or enables or participates in) the service being 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, via a malicious service application or via a legitimate service application that has a security flaw/vulnerability, to access such credentials, then that attacker may be able to conduct unauthorized transactions or obtain unauthorized services in relation to not only that particular service application, but also potentially in relation to other service applications that that user may make use of. For example, if an attacker is able to obtain the user's credentials via a security vulnerability in a service application executing on a user's device that accesses person health records, then the attacker may also be able to use those credentials to conduct an unauthorized financial transaction via a payment application installed on the user's device. Protection and security measures implemented by a first service application may be negated, or made less effective, if a second service application (over which the developers of the first service application have no control) is implemented in a less secure way.

With that in mind, the present invention provides an authenticator application that executes alongside one or more service applications. As discussed in more detail later, the authenticator application may, in response to a request from a service application, obtain credentials of a user, encrypt those credentials using a public key of a remote entity (that is to perform or provide a desired service associated with the requesting service application), and provide those encrypted credentials back to the service application. The service application does not, itself, obtain the user credentials from the user. The service application is, therefore, prevented from accessing the credentials of the user (as service application does not have the remote entity's private key that is needed to decrypt the encrypted credentials). An attacker cannot therefore make use of a malicious service application, or a security vulnerability in another service application, to access and misuse the user's credentials.

Moreover, the ability of multiple service applications to make use of the same authenticator application in this way provides various further technical benefits. In particular, the use of such an authenticator application allows for a quicker and easier way of performing a security update - updating the authenticator application provides updated security for all of the service applications that make use of the authenticator application (as opposed to having to perform an update on each and every service application). Furthermore, memory on the user's device is more effectively utilized - the size of the service applications ends up being reduced as they no longer themselves need to have their own functionality for obtaining the user's credentials via the user interface of the device and then securing those credentials. This benefit is enhanced as more and more service applications make use of the authenticator application.

Implementations herein are directed toward a system for providing consent architecture that includes an authenticator application that provides secure authentication to a service application (e.g., a payment application) for use with a remote entity (e.g., a financial institution). When obtaining an operation request from the 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 may only provide some credentials a single time to the authenticator application independent of the number of service applications used.

Referring to <FIG>, in some implementations, an example system <NUM> includes a user device <NUM> associated with a respective user <NUM> and in communication with a remote authentication system <NUM> (herein also referred to as a authentication server), a remote service application system <NUM> (herein also referred to as a service application server), and a remote entity system <NUM> (herein also referred to just as the remote entity) via a network <NUM>. The user device <NUM> may correspond to any computing device, such as a desktop workstation, a laptop workstation, or a mobile device (i.e., a smart phone). The remote systems <NUM>, <NUM>, <NUM> may be a single computer, multiple computers, or a distributed system (e.g., a cloud environment) having scalable / elastic computing resources (e.g., data processing hardware) and/or storage resources (e.g., memory hardware).

The user device <NUM> (e.g., a mobile phone) associated with the user <NUM> may include associated memory hardware <NUM> and associated data processing hardware <NUM>. The user device <NUM> leverages the memory hardware <NUM> and data processing hardware <NUM> to store and execute one or more service applications <NUM>, 140a-n (also referred to as a service app). In some examples, the service application <NUM> is a payment application that facilitates transferring funds in real-time from an account of a payer (i.e., a user account of the user <NUM>) to a payee, as described in more detail below. The service application <NUM> may execute as a standalone program on the user device <NUM> or, for example, in a web browser. The service application <NUM> obtains, receives, and/or generates an operation request <NUM>. The operation request <NUM> is generally created in response to user action. For example, when the service application <NUM> is a payment application, the user <NUM> may initiate an operation request <NUM> by attempting to transmit funds through the payment application. In some examples, the service application <NUM> generates the operation request <NUM> in response to commands from the user <NUM>. In other examples, the service application <NUM>, through the network <NUM>, communicates with the service application server <NUM> and the service application server <NUM> generates the operation request <NUM> and sends the operation request <NUM> to the service application <NUM>.

The operation request <NUM> includes a remote entity identifier 142a along with additional operation information 142b associated with the operation. The remote entity identifier 142a identifies the remote entity <NUM> associated with the operation request <NUM>. For example, the remote entity identifier 142a may be a name or other unique identifier of the financial institution the user <NUM> has associated with the service application <NUM>. The operation information 142b may include a host of information necessary or helpful for conducting the operation (<FIG>). For example, when the operation request <NUM> involves 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 that identifies an account of the user associated with the remote entity, and/or a payee identifier that identifies the payee.

The user device <NUM> also executes an authenticator application <NUM>. As used herein, the authenticator application <NUM> may also be referred to as the authenticator app, authentication application, or authentication app. The authenticator application <NUM> receives an authentication request <NUM> from the service application <NUM>. The authentication request <NUM> requests that the authenticator application <NUM> obtain user authentication credentials <NUM> associated with the remote entity <NUM> in order to authenticate the user <NUM> prior to the remote entity <NUM> performing an operation <NUM> associated with the operation request <NUM>.

The user <NUM> provides user credentials <NUM> for one or more remote entities <NUM> (e.g., financial institutions) to the authenticator application <NUM>. That is, the user <NUM> provides the authenticator application <NUM> with the credentials <NUM> necessary to access an account <NUM> (<FIG>) of the user <NUM> at a remote entity <NUM>. The user <NUM> may provide separate credentials <NUM> for any number of remote entities <NUM>. Put another way, the user may "register" any number of user accounts with any number of remote entities <NUM> with the authenticator application <NUM>. The user credentials <NUM> may be a username and password, a personal identification number (PIN), one-time password (OTP), a unique device key, or any other data the remote entity <NUM> requires for authentication or cryptographic attestation (i.e., a claim that can be cryptographically verified). In some examples, the user <NUM> registers a single account from the remote entity <NUM> with the authenticator application <NUM>, while in other examples, the user <NUM> registers all accounts associated with the remote entity <NUM> simultaneously.

In addition to receiving user credentials <NUM> from the user <NUM> for a respective remote entity <NUM>, the authenticator application <NUM> retrieves a public key <NUM> associated with the respective remote entity <NUM>. The public key <NUM> makes up one of the keys in a key pair used in public-key cryptography (also referred to as asymmetric cryptography). In public-key cryptography, cryptographic algorithms generate a private key and a corresponding public key that produce one-way functions such that data encrypted with the public key may only be decrypted by the associated private key. In this example, the remote entity <NUM> publically provides its public key <NUM> and keeps hidden the associated private key <NUM>. Thus, once the user credentials <NUM> are encrypted by the authenticator application <NUM> with the public key <NUM> of the remote entity <NUM>, only the remote entity <NUM> (with the associated hidden private key <NUM>) may decrypt the encrypted credentials <NUM>. In this way, the service application <NUM> is restricted from obtaining the user authentication credentials <NUM> in unencrypted form.

In addition to encrypting the user credentials <NUM>, the authenticator application <NUM> optionally encrypts additional information <NUM> with the credentials <NUM>. For example, the authenticator application <NUM> may encrypt additional transaction details (e.g., transaction amount, account identification, description, etc.) along with other information such as a current timestamp and unique identification to form an encrypted package <NUM>. As discussed in more detail below, this additional information <NUM> may serve to provide additional authentication and verification of the operation.

The authenticator application <NUM> provides the encrypted user package <NUM> to the service application <NUM>. As previously discussed, the service application <NUM> lacks the private key <NUM> of the remote entity (i.e., the key associated with the public key <NUM> used to encrypt the user credentials <NUM>) and thus cannot access the unencrypted credentials <NUM>. The service application <NUM> transmits the operation request <NUM>, now including the encrypted package <NUM>, to the remote entity <NUM>. The remote entity <NUM>, decrypts the package <NUM> (including the encrypted credentials <NUM>) from the received operation request <NUM> with a request decryptor <NUM> using the associated private key <NUM> and validates the decrypted credentials <NUM> with a credential validator <NUM>.

Referring now to <FIG>, in some implementations, the system <NUM> includes the remote entity <NUM> including financial institution 130F associated with the user <NUM> and the service application <NUM> including a payment application 140P. In this case, the operation request <NUM> is an electronic payment request 142P requesting the payment application 140P to initiate the electronic payment from the financial institution to a payee. For example, the user device <NUM> may launch the payment application 140P to transfer funds to a payee. The payment application 140P typically asks for operation information 142b such as an identity of the payee, an amount of the transaction, and an account the user <NUM> wishes to draw the funds from. A payment confirmation from the user <NUM> (e.g., the user <NUM> pressing a "Confirm Payment" button <NUM>) may initiate the authentication request <NUM> from the payment application 140P to the authenticator application <NUM>.

Real time payment networks <NUM> (herein also referred to as verification networks) are maintained by some central authorities (e.g., governments of countries) to facilitate interbank retail payments. That is, RTP networks may act as a clearing house and settle funds across issuers in a similar fashion as credit card networks that handle interchange and settlements with credit card operations. For example, India maintains the National Payments of India that includes an immediate payment service that is a real time inter-bank payment system. Similarly, Mexico operates Banxico to maintain immediate payment services in Mexico. Generally, real time payments must be verified and/or authenticated by the RTP networks before the payment is approved. In some instances, the central authority (e.g., the government) does not provide a RTP network and instead all verification and authentication is left to the individual financial institutions. The RTP networks and/or financial institutions often provide access to the RTP network via application programming interfaces (APIs). For example, some RTP networks offer payment initiation service provider (PISP) APIs.

Still referring to <FIG>, a real time payment network (RTP network) <NUM> may be in communication with network <NUM>. The payment application 140P may be a non-financial institution that has access to the network <NUM> via APIs and is able to initiate payments. The payment application 140P, in some examples, is a standalone application, and in other examples, is executed in a web browser. In some implementations, the payment application 140P, after receiving the encrypted package <NUM> from the authenticator application <NUM>, sends the package <NUM> to a payment application server 120P (or simply 'payment server 120P') along with the payment request 142P. The payment application server 120P is a computing entity that relays requests from the payment application 140P to the RTP network <NUM>. The payment server 120P typically is authenticated by the RTP network <NUM>. That is, the payment server 120P must prove to the RTP network <NUM> that the server 120P is a genuine server in service to the approved payment application 140P. Once authenticated, the payment server 120P forwards the received package <NUM> and request 142P to the RTP network <NUM>.

As discussed in greater detail below, the RTP network <NUM> may perform a set of validations prior to approving the transaction. These validations may be in addition to any validations the financial institution 130F requires. To secure the RTP network operations, the authenticator application <NUM> may encrypt some or all of the credentials <NUM> with an RTP network public key <NUM>. Like the remote entity public key <NUM> (i.e., the public key of the financial institution 130F), the RTP network public key <NUM> may be one of a pair of key used in public-key cryptography while the RTP network keeps an associated secret network private key <NUM>. In some implementations, the network <NUM> has a separate master signing key <NUM> used to establish authenticity of the RTP network <NUM>. All data signed by this key may be verified using the corresponding master public key. For example, the authenticator app <NUM> may receive a Diffie-Hellman (DH) key from the network <NUM> signed by the master signing key <NUM> so that the authenticator app <NUM> may verify the authenticity of the DH key. The master public key may be hardcoded into the authenticator app <NUM>, as it may have a very long expiration time. Some or all of the user credentials <NUM> may be encrypted with either or both the remote entity key <NUM> and the network key <NUM>. When the credentials <NUM> are encrypted with both, the RTP network <NUM> may decrypt the encrypted package <NUM> using the network private key <NUM> prior to forwarding the package <NUM> and request 142P on to the remote entity <NUM> so that the remote entity <NUM> may decrypt and access its portion of the package <NUM>.

After the financial institution 130F receives the payment request 142P from either the RTP network <NUM>, the payment application server 120P, or, in some examples, directly from the payment application 140P, the financial institution 130F validates any operation information 142b included within the operation request <NUM>. For example, the financial institution 130F may validate that the operation information 142b (e.g., transaction amount, account identification, etc.) from the operation request <NUM> matches the additional information <NUM> encrypted by the authenticator application <NUM>. In some examples, the financial institution 140F verifies that a phone number associated with the mobile device that sent the request matches a phone number associated with the account being accessed. If the financial institution 140F desires (e.g., if the transaction is suspicious), the financial institution may issue one or more challenge requests <NUM> requesting additional user authentication credentials <NUM> to the user <NUM>. Any challenge requests <NUM> from the financial institution 130F may be forwarded back through the RTP network <NUM> to the payment server 120P, the payment application 140P, and finally back to the authenticator application <NUM> where the authenticator app <NUM> may obtain and encrypt the obtained additional user authentication credentials <NUM> from the user <NUM> to satisfy the challenge request <NUM> with a challenge response <NUM> (<FIG>). The financial institution 140F may similarly decrypt the encrypted additional user authentication credentials <NUM> from the challenge response <NUM> and validate the decrypted additional user authentication credentials <NUM> to satisfy the challenge request <NUM>. Once the financial institution 130F accepts the transaction, the funds are transferred and the financial institution 130F may pass acknowledgement back to the RTP network <NUM>, which in turn flows back to the user <NUM> as a notification <NUM>. For example, the payment application 140P may display a visual indication of success and/or play audible message.

While in the context of the previous example the service application <NUM> was described as a payment application 140P and the remote entity <NUM> was described as a financial institution 130F, the authenticator application <NUM> is applicable in any situation where the user <NUM> is transferring sensitive information via an untrusted third-party application to a remote entity. For example, the user <NUM> may initiate an information retrieval request 142R for records (e.g., private al records that the remote entity has an obligation to keep confidential) or other private information associated with the user from a private records datastore without exposing user credentials <NUM> in cleartext/plaintext. Referring now to <FIG>, in some implementations, the authenticator application <NUM> encrypts user credentials <NUM> to enable access to a private records datastore <NUM> storing private information <NUM> associated with the user <NUM>. The private datastore <NUM> may be an online repository of sensitive information (e.g., health records). The remote entity <NUM>, after receiving the information retrieval request 142R from the service application <NUM>, decrypts the encrypted package <NUM> at the request decryptor to obtain decrypted credentials 154D and validates the credentials at the credential validator <NUM>. After successful validation, the remote entity <NUM> retrieves one or more user records <NUM> from the private records datastore <NUM> storing private information. The remote entity may return the retrieved records <NUM> to the user <NUM> via the user device <NUM> or, if authorized, transfer the records to a third-party. For example, the user <NUM> may authorize a private records company to transfer private records to a facility that requires the records without the service application <NUM> learning any information necessary to obtain the records (e.g., a social security number).

The authenticator application <NUM>, service application <NUM>, network <NUM>, and remote entity <NUM>, in some implementations, provide a secure environment by performing a set of standard validations at every application step. For example, every time the authentication app <NUM> receives a request from the service app <NUM>, the authenticator app <NUM> may verify a service app identification (ID) (i.e., an identification that uniquely identifies the service app <NUM>) and/or an authorization certificate or some other form of authorization token <NUM> from the service app <NUM>. The service app <NUM>, whenever communicating with the service app server <NUM>, may verify the server's certificate (e.g., via x509 certificate signing). The service app server <NUM>, in some examples, authenticates the service app user and authenticates to the network <NUM> using mutual Secure Sockets Layer (SSL) or Pretty Good Privacy (PGP) encryption as standard validation.

The network <NUM>, whenever it receives a request from the service app server <NUM>, may perform a variety of checks. For example, the network <NUM> may authenticate the service app server <NUM> using mutual SSL or PGP encryption. The network <NUM> may decrypt data from the authenticator app <NUM> using the network private encryption key <NUM>. The network <NUM> may also verify the signature of any signed messages from the authenticator app <NUM> (e.g., via a public key of the user device <NUM> (<FIG>)). In some implementations, the network <NUM> ensures that the service app ID matches an ID provided by the service app server and ensures that any authentication done by the authenticator app <NUM> is recent by, for example, comparing the timestamp captured by the authenticator app <NUM> to the current time. The network <NUM> may invalidate any operations that are sufficiently stale (e.g., to prevent replay attacks). Optionally, the network <NUM> maintains a whitelist of all service applications <NUM> authorized to access the consent architecture and the associated service app ID. The network <NUM> may maintain a repository of public keys of servers corresponding to the whitelisted service applications for proper server to server authentication.

In some implementations, the user <NUM> registers or initializes the user device <NUM> and the authenticator application <NUM> with the service application <NUM> prior to use. This registration provides for a strong binding between the device <NUM>, a digital identify of the user <NUM> (which may be shared with the service application <NUM>), and the actual identify of the user <NUM> (which may be shared with the remote entity <NUM> or network <NUM>). In some examples, the authenticator application <NUM> is a trusted app. That is, the authenticator application <NUM> is trusted by the network <NUM> and/or the remote entity <NUM> to provide assertions of verified user information.

Referring now to <FIG>, registration of the service application <NUM> typically begins via a request from the user <NUM> (e.g., via actuating a user input <NUM> within the service application). The service application <NUM> collects various user information <NUM>, such as name, phone number, a unique identifier, and/or any other user information the service application <NUM> desires for authentication (<FIG>). In some examples, the service application <NUM> verifies the user information <NUM> with the service application server <NUM>, while in other examples the service application <NUM> has already pre-verified the information. For example, some service applications <NUM> may already have pre-verified phone numbers for some users. For some applications, the service application <NUM> may collect identification or identifying information that may be verified by, for example, by querying a central database.

Referring now to <FIG>, after collecting and verifying the user information <NUM>, the service application <NUM> invokes the authenticator application <NUM> by sending a service registration request <NUM> that includes application registration information <NUM>, 604a-c. This information <NUM> provides data that the authenticator application <NUM> uses to verify and authenticate the registration. For example, the registration information <NUM> may include the service application ID 604a, a user identification (user ID) 604b that uniquely identifies the user <NUM> in the service app <NUM> namespace (i.e., no other user of the service app <NUM> has the same user ID), and a consent identification nonce 604c. The service application ID 604a may be used to verify that the service application <NUM> is an authorized application. The consent identification nonce 604c may be used to combat replay attacks. The authenticator application <NUM> uses the user ID 604b, as discussed below, to generate unique, user-specific keys.

The authenticator app <NUM> receives the service registration request <NUM> and may perform the set of standard validations discussed above. The authenticator app <NUM> generates a unique device key pair <NUM> used to uniquely prove the identity of the device <NUM>. A private key 606R of the key pair is stored in a secure element 615within the device (e.g., within the memory hardware <NUM>) while a corresponding public key 606U is provided to the public (e.g., the network <NUM> and/or remote entity <NUM>). The secure element <NUM> ensures that any user or application of the device <NUM> cannot gain access to the private key 606R. The authenticator app <NUM> may generate the device keys <NUM> using the service application ID 604a, the user ID 604b, and unique device information (e.g., a serial number, etc.). In this way, the authenticator application <NUM> generates unique device keys <NUM> for each user of each service application <NUM>.

Referring now to <FIG>, in some examples, use of the private key 606R is protected by a user challenge <NUM>. For example, before the user device <NUM> signs a message with the private key 606R (i.e., to authenticate the message), the user device <NUM> may prompt the user <NUM> to enter a password or provide another identifier usable to authenticate the user. Thus, messages signed by the device private key 606R inherently imply two factors of both user and device authentication.

Referring back to <FIG>, the authenticator app <NUM>, in some implementations, signs a service registration response <NUM> that includes the service app identification 604a, the consent nonce 604c, and/or any certificates of the service application <NUM> with the device private key 606R. The attestations by these keys may be provided by an operating system of the user device <NUM> to validate the integrity of the device and the strength and properties of the keys <NUM>. The authenticator app <NUM> returns the signed response <NUM> (including the signed service application identification 604a) to the service app <NUM> which initiates a registration request with the service app server <NUM> (<FIG>). The service app server <NUM> initiates a registration request with, in some examples, the network <NUM>, and in other examples, with the remote entity <NUM>. The service app server <NUM> sends the unique user ID 604b (or a unique derivative of it, e.g., a hash) that uniquely identifies the user <NUM> with the service application <NUM> to the network <NUM> (or the remote entity <NUM>). Other verification information (e.g., phone number, unique identifier, the device public key 606U, etc.) may also be sent.

The network <NUM> or remote entity <NUM>, after receiving the registration request, may perform the set of standard validations discussed above and verifies the properties of the device key 606R. The network <NUM> or remote entity <NUM>, in response to successful validation, creates a profile ID <NUM> that includes an association between the user <NUM>, the service app <NUM>, and the device <NUM> (e.g., using service application ID 604a, the user ID 604b, the verified phone number, unique identifier, etc.) and sends the profile ID <NUM> back to the service app server <NUM>, which stores the profile ID <NUM>, thus completing user registration. The service app <NUM> may provide the user <NUM> confirmation of the successful registration. User registration allowed the network <NUM> and/or remote entity <NUM> to reliably establish that a digital identity defined by the service app <NUM> has possession of valid user information <NUM> (e.g., a verified phone number), possession of the user device <NUM>, and consented to registration. The service app server <NUM> has stored the profile ID which associates the user <NUM> with the service app <NUM> and user information <NUM>. The authenticator app <NUM> has stored the generated device keys <NUM> that are specific to the user <NUM> and the service app <NUM> that may be used as an attestation.

After user registration with the service app <NUM>, the user <NUM>, in some implementations, registers an account (or multiple accounts) with a remote entity <NUM> to establish a binding between the user device <NUM>, the profile ID <NUM>, and the associated account. Referring now to <FIG>, the user <NUM> creates an account registration request <NUM> (<FIG>) by providing a user input indication <NUM> (e.g., selecting a graphical element displayed on a graphical user interface executing on the device <NUM>). The service app <NUM> may respond by providing a valid institutions list <NUM> (<FIG>) for display on the graphical user interface for the user <NUM> to select from. The list <NUM> may be fetched from the service app server <NUM> or network <NUM> periodically and may include metadata such as name, logos, etc. The list <NUM> may be cached on the memory hardware <NUM> of the user device <NUM> between periodic updates. The user <NUM> may provide input indications using touch, stylus, speech, gesture, or any other input mechanism to select from the list <NUM> and/or providing the input indication <NUM> for initiating the account registration request <NUM>.

Referring now to <FIG>, in some implementations, the service app <NUM> requests verification of device ownership from the authenticator app <NUM> by sending the account registration request <NUM> to the authenticator app <NUM>. The account registration request <NUM> includes at least the user ID 604b. The authenticator app <NUM> may perform the aforementioned standard validations which establish that the account binding request (i.e., the account registration request <NUM>) originated from the same device <NUM> that performed the associated user registration (see <FIG>). The authenticator app <NUM> signs (with the device key 606R as shown in <FIG>) an account registration response <NUM> that includes, for example, an identifier of the service app <NUM> and the current timestamp, establishing a factor of device possession. The authenticator app <NUM>, in some examples, further issues a challenge <NUM> to the user (<FIG>) to establish a second factor of knowledge or inherence. The signed account registration response <NUM> is returned to the service app <NUM>.

The service app <NUM>, in some implementations, requests the network <NUM> or the remote entity <NUM> to list the user's <NUM> associated accounts by sending the signed response <NUM>, the profile ID <NUM>, and identification of the remote entity <NUM> (when sending to the network <NUM>) via, for example, the service application server <NUM>. The network <NUM> or remote entity <NUM> may perform its standard validations and verifies any application user information <NUM> (e.g., the verified phone number, the unique identifier, etc.). In some examples, the network <NUM> passes a request to list applicable accounts (i.e., accounts belonging to the user <NUM>) along with passing any necessary identification data (e.g., the phone number or unique identifier) to the remote entity <NUM>. The remote entity <NUM> may return an account list <NUM> back to the service app server <NUM>, whereby the account list <NUM> is associated with the user based on the identification data. The account list <NUM> may include additional metadata <NUM>, such as a name associated with the account, account name, account reference ID, and at least a portion of a unique account identifier (e.g., the last four digits of the account number). Optionally, the remote entity <NUM> can issue additional challenges <NUM> at this point. For example, the remote entity <NUM> may 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 implementations, such a challenge is triggered if one factor matches, but a different factor does not. For example, identification from an external database (e.g., the unique identifier) of the user matches, but the phone number does not. This may initiate "Yellow Path" authentication (i.e., authentication that requires additional verification). Challenges may be encrypted for additional security. For example, the challenges may be encrypted using a session key from a DH key exchange.

The service app server <NUM> relays the account list <NUM> to the service app <NUM> executing on the user device <NUM> for display to the user <NUM>. In some implementations, the user <NUM> selects a particular account from the account list <NUM> associated with the user <NUM>. The user <NUM>, in some implementations, selects all available accounts. The service app <NUM> may again verify device ownership from the authenticator app <NUM> and capture any data necessary to satisfy challenges from the remote entity <NUM>. In this case, the service app <NUM> passes the user ID 604b and the signed remote entity encryption key to encrypt the challenge data. After again performing any standard validations, the authenticator app <NUM> challenges the user (e.g., requests the user to unlock the user device, enter a password, etc.) to confirm possession and issue any challenge data from the remote entity. The authenticator app <NUM> encrypts any challenge results, a current timestamp, and the service app ID with the remote entity <NUM> key and signs the encrypted challenge response <NUM>.

The authenticator app <NUM> passes the signed and encrypted response <NUM> to the service app <NUM>, which in turn passes it and a binding request <NUM> to the service app server <NUM>. The service app server <NUM> passes the data to the network <NUM> or the remote entity <NUM> along with the profile ID <NUM>, remote entity ID, and any necessary account ID <NUM> (i.e., an identification that uniquely identifies the selected account). The service app server <NUM> may also generate an association ID <NUM> to represent the account binding and pass this ID <NUM> to the network <NUM>/remote entity <NUM> as well. The remote entity <NUM> receives the binding request <NUM> (from either the network <NUM> or the service app server <NUM>) and decrypts and verifies any challenge data. The remote entity <NUM> then stores the binding <NUM> between the selected account(s) and the device public key 606U and represented by the association ID. The remote entity <NUM> may note any details about any issued challenges to help 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 <NUM> may verify device attestations prior to or during future transactions.

Thus, during account registration, the remote entity <NUM> stores a binding <NUM> between the remote entity account ID and the device public key 606U represented by the association ID <NUM>. The authenticator app <NUM> has registered a key pair <NUM> that represents this binding and any future attestations signed by the private key 606R of the key pair provides proof of device ownership as well as a second factor of inherence. The service app server <NUM> stores a variety of data regarding the binding. For example, the service app server <NUM> may store the association ID, remote entity account metadata, the profile ID <NUM>, the user ID 604b, and the device ID. In this way, the authenticator app <NUM> securely passes data to the network <NUM> and the remote entity <NUM> while simultaneously ensuring that the network <NUM> and the remote entity <NUM> may verify that any data was captured on the device registered during user registration.

<FIG> is a flowchart of an exemplary arrangement of operations for a method <NUM> of authenticating operations within consent architecture. The method <NUM> starts at operation <NUM> with obtaining, at data processing hardware <NUM> of a user device <NUM> executing a service application <NUM> and an authenticator application <NUM>, an operation request <NUM> requesting the service application <NUM> to access a remote entity <NUM> to perform an operation <NUM>. The operation request <NUM> includes a remote entity identifier 142a identifying the remote entity <NUM> and operation information 142b associated with the operation <NUM>. At operation <NUM>, the method <NUM> includes issuing, by the service application <NUM> executing on the data processing hardware <NUM>, an authentication request <NUM> requesting the authenticator application <NUM> to obtain user authentication credentials <NUM> of a user <NUM> of the user device <NUM> associated with the remote entity <NUM> for authenticating the user <NUM> before the remote entity <NUM> performs the operation <NUM>.

At operation <NUM>, the method <NUM> includes encrypting, by the authenticator application <NUM> executing on the data processing hardware <NUM>, the obtained user authentication credentials <NUM> using a public key <NUM> of the remote entity <NUM>. The service application <NUM> is restricted from obtaining the user authentication credentials <NUM> in unencrypted form. At operation <NUM>, the method <NUM> also includes providing, by the authenticator application <NUM> executing on the data processing hardware <NUM>, the encrypted user authentication credentials <NUM> to the service application <NUM>, and at operation <NUM>, the method <NUM> includes transmitting, by the service application <NUM> executing on the data processing hardware <NUM>, the operation request <NUM> to the remote entity <NUM>. The operation request <NUM> includes the encrypted user authentication credentials <NUM>. The operation request <NUM>, when received by the remote entity <NUM>, causes the remote entity <NUM> to decrypt the encrypted user authentication credentials <NUM> using a private key <NUM> of the remote entity <NUM> and validate the decrypted user authentication credentials <NUM>.

For example, it may be implemented as a standard server 1100a or multiple times in a group of such servers <NUM>100a, as a laptop computer <NUM>100b, or as part of a rack server system <NUM>100c.

Claim 1:
A method (<NUM>) comprising:
obtaining, at data processing hardware (<NUM>) of a user device (<NUM>) executing a service application (<NUM>) and an authenticator application (<NUM>), an operation request (<NUM>) requesting the service application (<NUM>) to access a remote entity (<NUM>) to perform an operation (<NUM>), the operation request (<NUM>) comprising:
a remote entity identifier (142a) identifying the remote entity (<NUM>); and
operation information (142b) associated with the operation (<NUM>);
issuing, by the service application (<NUM>) executing on the data processing hardware (<NUM>), an authentication request (<NUM>) requesting the authenticator application (<NUM>) to obtain user authentication credentials (<NUM>) of a user (<NUM>) of the user device (<NUM>) associated with the remote entity (<NUM>) for authenticating the user (<NUM>) before the remote entity (<NUM>) performs the operation (<NUM>);
encrypting, by the authenticator application (<NUM>) executing on the data processing hardware (<NUM>), the obtained user authentication credentials (<NUM>) using a public key (<NUM>) of the remote entity (<NUM>) so that the service application (<NUM>) is restricted from obtaining the user authentication credentials (<NUM>) in unencrypted form;
providing, by the authenticator application (<NUM>) executing on the data processing hardware (<NUM>), the encrypted user authentication credentials (<NUM>) to the service application (<NUM>); and
transmitting, by the service application (<NUM>) executing on the data processing hardware (<NUM>), to the remote entity (<NUM>), the operation request (<NUM>) and the encrypted user authentication credentials (<NUM>), the operation request (<NUM>) and the encrypted user authentication credentials (<NUM>) when received by the remote entity (<NUM>) causing the remote entity (<NUM>) to:
decrypt the encrypted user authentication credentials (<NUM>) using a private key (<NUM>) of the remote entity (<NUM>); and
validate the decrypted user authentication credentials (<NUM>).