Trust Token for Resource Access

Abstract

A system and method are provided that include receiving an indication that a user has been authenticated from a first application on a user device, and receiving an indication that the user has been detected from a second application on the user device. The user device receives the indication that the user has been detected from a wearable device on the user. Based on receiving both indications within a period of time, a trust token is generated or maintained for the user.

Description

[0001] Cross - Reference to Related Applications

[0002] This application is a PCT application that claims priority to U.S. Provisional Application No. 62 / 778,106, filed on Dec. 11, 2018, which is incorporated herein by reference in its entirety. Background Art

[0003] Access to secure resources can be granted based on one or more authentication methods. For example, a user may log in to a secure website or application. As another example, a user may submit credentials or biometrics to gain access to a secure building. The more secure the resource, the more authentication may be required. For example, a secure resource may require escalating authentication or multiple forms of identification. As these authentication methods become more cumbersome, it can become increasingly burdensome for a user to regain access to the resource. For example, a user may log in to a bank website with a username and password. Then, the user may need to perform an escalating authentication process by entering an access code received via text message. If the user has to re - log in after a session has expired, the user may have trouble when having to go through multiple authentication phases again.

[0004] To avoid the need to re - authenticate users excessively, access to a resource can be extended for a period of time. One way to keep a user logged in to a website is to use a cookie. A cookie can be issued at the start of a session and expire at the end of the session. For example, a cookie may expire when the user manually logs out and / or after a period of time (e.g., 5 minutes). Using a cookie to extend a session is less secure. Cookies are vulnerable to being tampered with and exposed to multiple entities.

[0005] The embodiments, individually and collectively, solve these and other problems. Summary of the Invention

[0006] The methods described herein provide a way to extend a user's ability to securely access resources and use limited computing resources.

[0007] Embodiments include a method comprising: receiving, by a server computer, an indication that a user has been authenticated from a first application on a user device; receiving, by the server computer, an indication that the user has been detected from a second application on the user device, wherein the user device receives the indication that the user has been detected from a wearable device on the user; and generating or maintaining, based on receiving both indications within a period of time, a trust token for the user.

[0008] In some aspects, the method further includes: receiving, by the server computer, an indication that the user has not been detected from the second application on the user device; and revoking the trust token based on receiving the indication that the user has not been detected. In some aspects, the method further includes: determining, by the server computer, that the user has authorized access to user data associated with the user's digital identity, wherein the trust token is generated based on determining that the user has authorized the access to the user data associated with the user's digital identity. In some aspects, the method further includes: determining, by the server computer, that the user has revoked the access to the user data associated with the user's digital identity; and revoking the trust token by the server computer based on determining that the user has revoked the access.

[0009] In some aspects, the time period is a first time period, and the user has authorized access to the user data associated with the user's digital identity during a second time period, the method further includes: determining, by the server computer, that the second time period has expired; and revoking the trust token by the server computer based on determining that the second time period has expired. In some aspects, the method further includes: identifying, by the server computer, the digital identity of the user, wherein the trust token is stored in association with the digital identity of the user. In some aspects, the method further includes: periodically updating a record by the server computer based on the periodically received indication that the user has been detected, wherein the trust token is maintained based on the record.

[0010] In some aspects, the indication that the user has been detected corresponds to the detected heartbeat of the user. In some aspects, the method further includes: comparing, by the server computer, the detected heartbeat of the user with the stored heartbeat of the user; and determining, by the server computer based on the comparison, that the detected heartbeat matches the stored heartbeat, wherein further generating or maintaining the trust token is based on determining that the detected heartbeat matches the stored heartbeat.

[0011] An embodiment includes a server computer, including: a processor; and a computer-readable medium operatively coupled to the processor for performing the method as described above.

[0012] An embodiment includes a method that includes: determining, by a user device, that a user has been authenticated; sending, by the user device, an indication that the user has been authenticated to a server computer; determining, by the user device, that the user has been detected, wherein the user device determines that the user has been detected based on information generated by a wearable device based on detecting the user's heartbeat; and sending, by the user device, an indication that the user has been detected to the server computer, wherein the server computer generates or maintains a trust token for the user based on receiving two such indications within a period of time.

[0013] In some aspects, the method further includes: receiving, by the user device, an indication that the user has not been detected from the wearable device; and sending, by the user device, the indication that the user has not been detected to the server computer, wherein the trust token is revoked based on the indication that the user has not been detected. In some aspects, the method further includes: periodically sending, by the user device, additional indications that the user has been detected to the server computer, wherein the additional indications are for maintaining the trust token.

[0014] An embodiment includes a user device that includes: a processor; and a computer-readable medium operatively coupled to the processor for performing the method as described above. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Figure 1 A schematic diagram showing a system and method for managing a trust token according to some embodiments.

[0016] Figure 2 A block diagram showing a server computer according to some embodiments.

[0017] Figure 3 A block diagram showing a user device according to some embodiments.

[0018] Figure 4 A block diagram showing a digital identity platform according to some embodiments.

[0019] Figure 5 An example use case showing the use of a trust token according to some embodiments.

[0020] Figure 6 A flowchart showing a technique for using a trust token to grant access to a resource according to some embodiments. DETAILED DESCRIPTION

[0021] Before discussing various embodiments, some terms may be described in further detail.

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

[0023] "User device" may be any suitable device that can be operated by a user. User devices may include cellular phones, personal digital assistants (PDAs), pagers, tablet computers, personal computers, etc. As additional examples, user devices may include wearable devices (e.g., watches, rings, etc.). A user device may include any suitable hardware and software for performing such functions and may include multiple devices or components.

[0024] "Resource provider" may be an entity that can provide resources such as goods, services, information, and / or access. Examples of resource providers include merchants, data providers, shipping agents, government entities, venue and residential operators, etc. A resource provider may operate a resource provider computer.

[0025] The term "authentication" and its derivatives may refer to the process of verifying the credentials of an endpoint (including but not limited to applications, people, devices, processes, and systems) to ensure that the endpoint is what it claims to be.

[0026] The term "identifier" may refer to any information that can be used to identify something. In some embodiments, an identifier may be a special value that is randomly generated or generated according to a predetermined algorithm, code, or shared secret. For example, a driver's license number or a cryptographic key may be used to identify an individual. In some embodiments, an identifier may be in the form of one or more graphics, tokens, barcodes, quick response (QR) codes, or any other information that can be used to uniquely identify an entity.

[0027] "Identity attribute" may refer to a specific piece of information about an entity (e.g., a person, an organization, a thing, etc.). Examples of identity attributes include a social security number, age, phone number, and bank account number associated with a person.

[0028] "Digital identity" (DI) may include a set of security information about an entity (e.g., a person, an organization, or a thing). The DI may include multiple identity attributes, as well as a digital identity identifier that identifies the digital identity. For example, the DI of user Joe Smith may include: identity attributes such as the user's date of birth, social security number, address, and driver's license number; and an identifier such as Joe_Smith_1234 that is used to identify Joe Smith's digital identity. The DI may be made available to another entity in a secure manner. The DI may rely on agreements between stakeholders and security measures such as passwords.

[0029] A "trust token" can include an indicator that can be used to grant access to a resource. For example, a trust token can be used to extend the period during which a user remains authenticated to a security system. The trust token can be stored in a data store such as a cloud storage system managed by a server computer. The trust token can be binary or can include encoded information. The trust token can include or be stored in association with additional information such as a user identifier, an entity identifier, a timestamp, a digital identity, etc. In some embodiments, the trust token can be viewed by one or more entities to determine whether to grant access to one or more corresponding resources. The data store can store multiple trust tokens, each associated with a particular user and / or entity. For example, the trust token can be stored in association with a user identifier for an authenticated user and an entity identifier for the entity to which the user is authenticated.

[0030] An "access device" can be any suitable device for obtaining access to a resource. The access device can generally be located at any suitable location, such as at the location of a merchant. The access device can be in any suitable form. Some examples of access devices include point-of-sale (POS) devices, cellular phones, personal digital assistants (PDAs), personal computers (PCs), tablet computers, handheld dedicated readers, set-top boxes, electronic cash registers (ECRs), automated teller machines (ATMs), virtual cash registers (VCRs), information kiosks, security systems, access systems, websites, etc. The access device can use any suitable contact or non-contact operating mode to receive and transmit data from and to a payment device and / or a portable device, or data associated with a payment device and / or a portable device.

[0031] A "processor" can refer to any suitable one or more data computing devices. The processor can include one or more microprocessors that work together to achieve the desired function. The processor can include a CPU, which includes at least one high-speed data processor sufficient to execute program components for executing user- and / or system-generated requests. The CPU can be a microprocessor, such as AMD's Athlon, Duron, and / or Opteron; IBM's and / or Motorola's PowerPC; IBM's and Sony's Cell processor; Intel's Celeron, Itanium, Pentium, Xeon, and / or XScale; and / or one or more similar processors.

[0032] "Memory" can be any suitable one or more devices capable of storing electronic data. Suitable memories can include non-transitory computer-readable media that store instructions executable by a processor to implement the desired method. Examples of memories can include one or more memory chips, disk drives, etc. Such memories can operate using any suitable electrical, optical, and / or magnetic operating modes.

[0033] "Server computer" can include a powerful computer or a cluster of computers. For example, a server computer can be a mainframe, a small computer cluster, or a group of servers working as a unit. In one instance, a server computer can be a database server coupled to a web server. The server computer can be coupled to a database and can include any hardware, software, other logic, or a combination of the foregoing for servicing requests from one or more client computers. The server computer can include one or more computing devices and can use any of a variety of computing architectures, arrangements, and compilations to service requests from one or more client computers.

[0034] "Resource provider" can be any suitable entity that provides resources (e.g., goods, services, access to secure data, access to a location, etc.) during a transaction. For example, a resource-providing entity can be a merchant, a venue operator, a building owner, a government entity, etc. A "merchant" can generally be an entity that participates in a transaction and can sell goods or services or provide access to goods or services.

[0035] Embodiments provide a trust token that can be used to grant a user access to a resource. A trust token can be generated when confirmations are received from two applications within a period of time. For example, a first application can send a notification that a user has undergone an authentication process (e.g., via multi-factor authentication on a bank website, via a retina scan to gain access to a secure location, etc.). A second application can send an indication that the user is wearing a wearable device and that the wearable device is detecting the user's heartbeat. If two notifications are received within a threshold period of time, the server computer can issue a trust token that indicates that the user is trusted and can be granted access to the resource. For example, the trust token can keep the user logged in to the bank website without requiring multi-factor authentication, or can allow the user to gain access to a secure location without requiring another retina scan for a period of time. Alternatively or additionally, the user can be granted access to other resources during the period.

[0036] Figure 1A schematic diagram showing a system and method for managing trust tokens according to some embodiments. System 100 may include a server computer 106, a first user device 102, a second user device 104, an entity computer 108, and a data storage 109.

[0037] Figure 1 The components in the system shown in may communicate operatively with each other via any suitable communication channel or communication network. Suitable communication networks may be any one and / or combination of the following: direct interconnection, the Internet, local area network (LAN), metropolitan area network (MAN), operations as an Internet node (OMNI), secure custom connection, wide area network (WAN), wireless network (e.g., using protocols such as but not limited to Wireless Application Protocol (WAP), i - mode, etc.), and so on. Messages between computers, networks, and devices may be transmitted using secure communication protocols such as, but not limited to, File Transfer Protocol (FTP); Hypertext Transfer Protocol (HTTP); Secure Hypertext Transfer Protocol (HTTPS), Secure Sockets Layer (SSL), ISO (e.g., ISO 8583), etc.

[0038] For simplicity of illustration, Figure 1 a certain number of components are shown in. However, it should be understood that embodiments may include more than one of each component. For example, there may be multiple user devices operatively communicating with the entity computer 108 and / or the server computer 106, including the first user device 102.

[0039] The first user device 102 may be a device operable by a user and capable of executing application programs. For example, the first user device 102 may be a smart phone, a computer, a tablet computer, etc. The first user device 102 may execute various application programs. The components and functionality of example user devices such as the first user device 102 are further described below with respect to Figure 3 For example, the components and functionality of example user devices such as the first user device 102 are further described below with respect to

[0040] The entity computer 108 may be a server computer associated with an entity such as a resource provider. The entity computer 108 may be associated with the same entity that manages the first application 102A. For example, the first application 102A is a banking application, and the entity computer 108 is the server computer of the corresponding bank. As another example, the first application 102A is a merchant application (e.g., for online shopping), and the entity computer 108 is the server computer of the corresponding merchant. As another example, the first application 102A is a transportation application (e.g., for controlling access to a transportation system), and the entity computer 108 is the server computer of the corresponding transportation agent.

[0041] The second user device 104 can be a device capable of detecting a user. The second user device can be a wearable device, such as a smartwatch, an optical head-mounted display, a smart ring, etc. Alternatively, the second user device can be another type of device capable of detecting a user. For example, a mobile phone can detect user movement via touch. As another example, one or more monitoring cameras can be used to detect a user. The second user device 104 can include functionality for detecting a heartbeat (e.g., based on a detected pulse). The second user device 104 can include functionality for monitoring the characteristics of a heartbeat over time. The second user device 104 can include functionality for detecting and / or monitoring a pulse or other data regarding the user's wearable device. The second user device 104 can be communicatively coupled to the first user device 102 and / or the server computer 106. The second user device 104 can include functionality for notifying an application on the first user device 102 when a user is detected (or is no longer detected). Alternatively or additionally, the second user device 104 can include functionality for notifying the server computer 106 when a user is detected (or is no longer detected).

[0042] The application executed on the first user device 102 can include a first application 102A. The first application 102A can include functionality for authenticating a user. For example, the first application 102A can be a banking application. The banking application can prompt the user to enter a password, a personal identification number (PIN), biometric data, etc. This data can then be used to authenticate the user. As another example, the first application 102A can be an application for starting a vehicle in a keyless manner. Before activating the vehicle in a keyless manner at a certain initial time, the application can require the user to authenticate using biometrics, a password, etc.

[0043] The first application 102A can also include functionality for communicating with the server computer 106. The first application 102A can send a notification indicating that the user has been authenticated to the server computer 106.

[0044] The application executed on the first user device 102 can include a second application 102B. The second application 102B can include functionality for communicating with the second user device 104 (e.g., to send and / or receive messages regarding whether a user is detected). In some embodiments, the second application 102B can receive raw data (e.g., a pulse rate) from the second user device 104 and analyze the raw data to determine whether a user is detected. The second application 102B can include functionality for communicating with the server computer 106 (e.g., to send and / or receive messages regarding whether a user is detected).

[0045] In some embodiments, the first application 102A and the second application 102B may not be able to communicate directly with each other. For example, on a smart phone, for security purposes, applications may be isolated from each other. Communication between the first application 102A and the second application 102B may be partially or completely blocked. Thus, as an alternative, one application can send information to the server computer, and the server computer can send the information back to the other application. Alternatively, if the applications can communicate directly, some of the operations described herein with respect to the server computer can be performed on the first user device 102.

[0046] The server computer 106 may include functionality for generating and managing trust tokens. In some embodiments, the server computer 106 may generate a trust token based on the record 106A. Further details regarding server computers such as the server computer 106 are described in further detail below with respect to Figure 2 The server computer 106 may store the trust token 110 in a data store 109 (e.g., a cloud storage device), as described further below with respect to Figure 2 Further described.

[0047] The record 106A can be used to control access to a resource based on multiple conditions. The record 106A may also be referred to as a semaphore because the record 106A can represent the synchronization of two or more processes. The record 106A can be represented as a variable, an object, etc. The record 106A can be used to determine whether two positive indications have been received within a period of time. As Figure 1 shown, if the user (a) has been authenticated and (b) has been detected (e.g., via a heartbeat, pulse, monitoring system, etc.), the record 106A is positive (as indicated by the two checkboxes). The record 106A is represented as positive, for example, by being assigned a value of 1 or yes. The record 106A can be represented as negative (e.g., the user has not been authenticated and / or not detected) by being assigned a value of 0 or no, for example.

[0048] In some embodiments, if the user is authenticated and detected within a period of time, the record 106A can be positive. For example, the user is detected within one second of authentication. As another example, the user is continuously detected within a thirty-second window around the authentication time. The server computer 106 can use a timer to determine whether the user has been detected within a specific period of time. If the user is not detected, the record 106A can be modified to no longer be positive. If the record 106A is positive, the system can generate the trust token 110.

[0049] The trust token 110 can be an indicator established based on the record 106A. The trust token 110 can be used to indicate that a user should be granted access to a resource, as described in further detail below with respect to Figure 6 . The trust token 110 can be stored in a data storage area 109 such as a cloud storage system managed by the server computer 106. The trust token 110 can be stored including or in association with additional information such as a user identifier, an entity identifier, a timestamp, a digital identity, etc. In some embodiments, the trust token 110 can be viewed by one or more entities to determine whether to grant access to one or more corresponding resources.

[0050] If the user is not detected within a threshold time period, the trust token 110 can be revoked. For example, the threshold time period can be 30 seconds, 30 minutes, or 2 hours. As a specific instance, while a short time period without detecting a user's heartbeat may be permitted, if the user's heartbeat is not detected for 1 hour or longer, the trust token can be revoked.

[0051] Figure 2 A block diagram of a server computer 200 according to some embodiments is shown. The server computer 200 can include a processor 204. The processor 204 can be coupled to a memory 202, a network interface 206, and a computer-readable medium 208. The server computer 200 can include or be communicatively coupled to a data storage area 220.

[0052] The data storage area 220 can be a storage unit and / or device for storing data (e.g., a file system, a database, a collection of tables, or other storage mechanisms). The data storage area 220 can include multiple different storage units and / or devices. For example, the data storage area 220 can be a cloud storage system that is accessible by one or more physical computers on a limited basis (e.g., access can be controlled by a cryptographic key managed by the server computer 200, as described in further detail below with respect to Figure 4 .

[0053] The data storage area 220 can store trust tokens 222. As described above with respect to Figure 1 , trust tokens can be used to extend a user's authentication period based on a record. The data storage area 220 can store multiple trust tokens 222, each trust token associated with a specific user and / or entity. For example, the trust token 222 can be stored in association with a user identifier for an authenticated user and an entity identifier for the entity to which the user is authenticated. The trust token 222 can be stored in association with the user's digital identity.

[0054] The processor 204 may be implemented as one or more integrated circuits (e.g., one or more single-core or multi-core microprocessors and / or microcontrollers). The processor 204 may be used to control the operation of the server computer 200. The processor 204 may execute various programs in response to program code or computer-readable code stored in the memory. The processor 204 may include the function of maintaining multiple simultaneously-executing programs or processes.

[0055] The memory 202 may be used to store data and code. The memory 202 may be coupled to the processor 204 internally or externally (e.g., a cloud-based data storage device), and may include any combination of volatile and / or non-volatile memory, such as RAM, DRAM, ROM, flash memory, or any other suitable memory device.

[0056] The network interface 206 may include an interface that may allow the server computer 200 to communicate with external computers. The network interface 206 may enable the server computer 200 to transmit data to or receive data from another device (e.g., the physical computer 108, an authorized computer, etc.). Some examples of the network interface 206 may include a modem, a physical network interface (e.g., an Ethernet card or other network interface card (NIC)), a virtual network interface, a communication port, a Personal Computer Memory Card International Association (PCMCIA) slot and card, and so on. The wireless protocols supported by the network interface 206 may include Wi-Fi TM . The data transmitted via the network interface 206 may be in the form of signals, which may be electrical, electromagnetic, optical, or any other signal (collectively referred to as "electronic signals" or "electronic messages") that can be received by an external communication interface. These electronic messages, which may include data or instructions, may be provided between the network interface 206 and other devices via a communication path or channel. As mentioned above, any suitable communication path or channel may be used, e.g., wires or cables, optical fibers, telephone lines, cellular links, radio frequency (RF) links, WAN or LAN networks, the Internet, or any other suitable medium. The network interface 206 may utilize long-range communication channels as well as short-range communication channels.

[0057] The computer-readable medium 208 may include one or more non-transitory media for storage and / or transmission. For example, suitable media include random access memory (RAM), read-only memory (ROM), magnetic media such as a hard disk drive or a floppy disk, or optical media such as a compact disc (CD) or a digital versatile disc (DVD), flash memory, etc. The computer-readable medium may be any combination of these storage or transmission devices.

[0058] The computer-readable medium 208 may include software code stored as a series of instructions or commands. The computer-readable medium 208 may include code executable by the processor 204 to implement a method that includes: receiving, by a server computer, an indication that a user has been authenticated from a first application on a user device; receiving, by the server computer, an indication that a user has been detected from a second application on the user device, wherein the user device receives the indication that the user has been detected from a wearable device on the user; and generating or maintaining a trust token for the user based on receiving the two indications within a period of time.

[0059] The computer-readable medium 208 may include a communication module 210, a record management module 212, a trust token generation module 214, and a trust token update module 216. Each of these modules may include code configured to perform the functions described below in conjunction with the processor 204.

[0060] The communication module 210 may include code that causes the processor 204 to generate messages, forward messages, reformat messages, and / or otherwise communicate with other entities.

[0061] The record management module 212 may include code that causes the processor 204 to generate and maintain records. The record management module 212 may cooperate with the processor 204 to generate records based on information received from the user device (e.g., the record 106A described above with respect to Figure 1 ). The record management module 212 may cooperate with the processor 204 and the communication module 210 to receive an indication from the user device specifying a user authentication state (e.g., the user recently logged in to a secure application on the user device). The record management module 212 may cooperate with the processor 204 and the communication module 210 to receive an indication from the user device specifying a user detection state (e.g., the user's heartbeat has been detected by an application coupled to the wearable device). Based on such information, the record management module 212 may cooperate with the processor 204 to update the record. The record management module 212 may further provide information about the record to the trust token generation module 214 and / or the trust token update module 216.

[0062] The trust token generation module 214 may include code that causes the processor 204 to generate a trust token. The trust token generation module 214 may cooperate with the processor 204 and the record management module 212 to monitor the record (e.g., the record described above with respect to Figure 1The described record 106A). If the record is affirmative (e.g., the user is authenticated and detected over a period of time), the trust token generation module 214 can cooperate with the processor 204 to generate a trust token 222. The trust token generation module can include code that causes the processor 204 to generate a trust token 222 associated with a particular user and store it in the data store 220 to generate the trust token 222.

[0063] The trust token update module 216 can include code that causes the processor 204 to update the trust token 222. The trust token update module 216 can cooperate with the processor 204 to monitor the record (e.g., the record 106A described above Figure 1 ). If the record changes, the trust token update module 216 can cooperate with the processor 204 to update the trust token 222. For example, if the record changes from affirmative to negative, the trust token update module 216 can cooperate with the processor 204 to revoke the trust token 222. Revoking the trust token 222 can include deleting the trust token 222, or modifying the trust token 222 to indicate that the trust token 222 is currently invalid. If the record changes from negative to affirmative, the trust token update module 216 can cooperate with the processor 204 to reinstate the trust token 222. Reinstating the trust token 222 can include generating a new trust token 222 based on a previously revoked trust token 222, or modifying an invalid trust token 222 to indicate that the trust token 222 is currently valid. The trust token update module 216 can cooperate with the processor 204 to perform actions to maintain the trust token (e.g., by keeping track of the time the trust token 222 is stored and / or updated and stored in association with the trust token 222).

[0064] The server computer 200 can further include one or more timers (not depicted). The timer can be a software timer and / or a hardware timer. The server computer 200 can use the timer to track the various time periods described above. For example, the server computer 200 can start the timer when the user has been authenticated, and, if the count of the timer is less than ten seconds when the server computer 200 confirms that the user has been detected, the server computer 200 can continue to generate the trust token 222. As another example, the server computer 200 can start the timer when the user has been authenticated, and, if the count of the timer reaches ten days, take the user off the grid.

[0065] Figure 3 A block diagram of a user device 300 according to some embodiments is shown. The user device 300 can include a processor 304. The processor 304 can be coupled to a memory 302, a network interface 306, and a computer-readable medium 308.

[0066] The memory 302, the processor 304, and the network interface 306 may be generally similar to the memory 202, the processor 204, and the network interface 306 described above with respect to Figure 2 the memory 202, the processor 204, and the network interface 306.

[0067] The computer-readable medium 308 may include one or more non-transitory media for storage and / or transmission. For example, suitable media include random access memory (RAM), read-only memory (ROM), magnetic media such as a hard disk drive or a floppy disk, or optical media such as a compact disc (CD) or a digital versatile disc (DVD), flash memory, and the like. The computer-readable medium may be any combination of these storage or transmission devices.

[0068] The computer-readable medium 308 may include software code stored as a series of instructions or commands. The computer-readable medium 308 may include code that can be executed by the processor 304 to implement a method, the method including: determining by the user device that the user has been authenticated; sending by the user device an indication that the user has been authenticated to the server computer; determining by the user device that the user has been detected, wherein the user device determines that the user has been detected based on information generated by the wearable device based on detecting the user's heartbeat; and sending by the user device an indication that the user has been detected to the server computer, wherein the server computer generates or maintains a trust token for the user based on receiving two indications within a period of time.

[0069] The computer-readable medium 308 may include a communication module 310, a security application 312, and a user detection application 314. Each of these modules may include code configured to perform the functions described below in conjunction with the processor 304.

[0070] The communication module 310 may include code that causes the processor 304 to generate messages, forward messages, reformat messages, and / or otherwise communicate with other entities.

[0071] The security application 312 may include code that causes the processor 304 to authenticate the user. The security application 312 may be generally similar to the first application 102A described above with respect to Figure 1 the first application 102A. The security application 312 may be an application to which the user should continuously authenticate, such as a banking application, an application for starting a vehicle in a keyless manner, or an application for logging into a secure file system.

[0072] The user detection application 314 may include code that causes the processor 304 to convey information regarding whether the user has been detected. The user detection application 314 may be generally similar to the one described above with respect to Figure 1The second application 102B described. For example, the user detection application 314 can be an application associated with a wearable device such as a smartwatch. The user detection application 314 can retrieve, analyze, and send information received from the wearable device.

[0073] Figure 4 FIG. shows a schematic diagram of an example system 400 for digital identity management according to some embodiments. As will be elaborated below, the digital identity management system 400 can be used in conjunction with the previously described trust token system to both protect sensitive user information and facilitate user interactions such as payment transactions. System 400 shows only one possible arrangement of the many possible arrangements of components configured to execute the programs described herein. Other arrangements may include fewer or different components, and the division of work among the components may vary according to the arrangement.

[0074] System 400 can include at least one Digital Identity (DI) provider 410, a server computer 402, a relying entity 408, an event log 404, a target entity 411, and a key vault 406. The components of system 400 can communicate operatively with each other via a communication network.

[0075] The communication network can include any suitable communication medium. The communication network can be one and / or a combination of the following: direct interconnection; the Internet; a Local Area Network (LAN); a Metropolitan Area Network (MAN); Operating as Nodes on the Internet (OMNI); a secure custom connection; a Wide Area Network (WAN); a wireless network (e.g., employing protocols such as, but not limited to, Wireless Application Protocol (WAP), i-mode, etc.), etc. Secure communication protocols can be used to transmit Figure 4 messages between the entities, providers, networks, and devices shown, such secure communication protocols as, but not limited to: File Transfer Protocol (FTP); Hypertext Transfer Protocol (HTTP); Secure Hypertext Transfer Protocol (HTTPS), Secure Sockets Layer (SSL), ISO (e.g., ISO 8583), etc.

[0076] In some embodiments, the target entity 411 is the entity for which a digital identity is provided (i.e., the digital identity regarding the target entity 411). The target entity 411 can include a user 411A of the target entity and / or a client device 411B. The term "target entity" can refer to an individual (e.g., a customer, a consumer, etc.), a business or other legal organization, a government agency, etc. Additionally or alternatively, the term "entity" can refer to a thing (e.g., an object, a piece of equipment, an electronic component, a computer system, etc.).

[0077] In some non - limiting embodiments, an identifier (“identifier of the target entity”) may be assigned to the target entity 411. The identifier of the target entity may include data associated with the digital signature and / or cryptographic key of the target entity 411. Alternatively or additionally, the identifier of the target entity may include an ID number, a Quick Response (QR) code, etc.

[0078] Information about the target entity may be retrieved from a source. One type of source is the DI provider 410. The DI provider 410 generates one or more digital identities (DIs) associated with the target entity 111. As described above, a DI may include data associated with a set of information about an entity that can be shared with another entity. The DI provider 410 may be an issuer, an acquirer, a transaction service provider, a government agency, etc. The DI provider 410 is configured to create and store DIs.

[0079] In some non - limiting embodiments, the relying entity 408 is an entity that is used to receive information associated with a user's digital identity. In some embodiments, the relying entity 408 may correspond to the entity computer 108 described above with respect to Figure 1 The relying entity 408 can be any entity that requests information about the target entity 411. For example, the relying entity 408 can be a merchant that requests information about the target entity 411 that initiates a payment transaction. Additionally or alternatively, the relying entity 408 can be an entity (e.g., a government agency or a corporate organization) that requests information about the entity 411 in the context of a non - payment interaction (e.g., granting the entity 411 access to a secure area or an event location).

[0080] In some non - limiting embodiments, an identifier (“identifier of the relying entity”) may be assigned to the relying entity 408. The identifier of the relying entity may include data associated with the digital signature and / or cryptographic key of the relying entity 408.

[0081] The event log 404 can be used to access event metadata for tasks such as dispute resolution, fraud detection, and / or user behavior analysis. By restricting access to the cryptographic keys required to access one or more events, the event structure helps to keep the data associated with the target entity confidential. For example, a private key held by the target entity may be required to access the event data, ensuring that the event data is only available with the explicit permission of the target entity. The access path for the event data can be defined via a general application programming interface (API) structure. The access path can be established such that limited entities can access events using a limited amount of data.

[0082] The event log 404 can be stored in any suitable computer-readable storage medium and / or any suitable combination of computer-readable storage media. For example, the event log 404 can be stored in a database. Additionally or alternatively, the event log 404 can be maintained and stored in a distributed ledger, including but not limited to blockchains and the like.

[0083] The system 400 can further include a key vault 406. The key vault 406 can be a file, a collection of files, or a database for storing cryptographic keys. The key vault 406 can be cloud-based. The key vault 406 can store cryptographic keys assigned to various entities (e.g., cryptographic keys assigned to the target entity 411, the DI provider 410, the dependent entity 408, etc.). The key vault 406 can organize keys based on the target entity 411 such that the keys of the parties that have participated in events associated with the target entity 411 are stored in a structure based on the target entity 411. This set of keys can be encrypted using the key of the target entity 411 such that the private key held by the target entity 411 is required to release the set of keys. Alternatively or additionally, a pair of key sets can also be assigned for each relationship. For example, a pair of key sets can be assigned to the target entity 411 and the dependent entity 408. The key vault 406 can store cryptographic keys associated with previous events involving the target entity 411.

[0084] In some embodiments, one or more of the keys can be encoded based on the Base58 model. Base58 is a binary-to-text encoding that uses fifty-eight easily distinguishable alphanumeric symbols and a payload of any size. Additionally, one or more keys can be encoded in Wallet Import Format (WIF). WIF is a method of encoding keys that facilitates copying keys and allows for compression. Some keys may or may not be encoded and / or encrypted based on an appropriate security level.

[0085] System 400 can manage the "on the grid" state. "On the grid" can include connecting to a computer network infrastructure and communicating with the computer network infrastructure. The on-the-grid state can indicate that the user has authorized access to user data associated with the user's digital identity. For example, being on the grid can include connecting to a network communication system. When a user device is connected to a network communication system, other devices can communicate with the user device to access information about the user, such as digital identity, user data, etc. For example, a device can communicate with the user device to retrieve a cryptographic key from the user device, which is then used to decrypt an assertion about the user. In an embodiment, the user can be authenticated before becoming "on the grid". In some embodiments, the user authentication status can be monitored when "on the grid" to remain "on the grid". Further details regarding this aspect can be found in PCT application No. PCT / US2019 / 064132, filed on December 3, 2019, which is assigned to the same assignee as the present application.

[0086] Applications such as mobile applications can be used to go on and off the grid. For example, an application can include a user interface for indicating the on-the-grid state. The user interface can represent that the user is on the grid in a first state and off the grid in a second state. The user interface can include graphical elements that can represent and / or control whether the user is on or off the grid. As another example, the user can interact with a checkbox or other element to accept user input via a website to control the on-the-grid state.

[0087] To go on the grid, the user can first perform an authentication operation and go on the grid. Then, a timer indicating the time remaining before going off the grid can be initialized to its maximum value, such as 8 hours.

[0088] When the user is on the grid, user data can be associated with the user's digital identity, which can be accessed by one or more relying entities. For example, the user data can be event data associated with the user. The user data can be in encrypted form and can be stored in a database such as event log 404.

[0089] When the user is on the grid, the server computer 402 can grant access to security event data. The server computer 402 can receive from a user device associated with the user (e.g., Figure 1The security element on the first user device 102 retrieves the cryptographic key associated with the user. Before retrieving the cryptographic key, the server computer 402 may determine that the user data request occurs within a time period during which the user has authorized access to the user data. For example, the server computer 402 may determine that the timestamp of the access request occurs within a time period during which the user has authorized parties to access the user data. The server computer 402 may use the user's cryptographic key to access the key vault 406. The first time period may be used to control records (e.g., Figure 1 record 106A), and another second time period may be used to control the networked state.

[0090] At any point in time after becoming networked, the user may decide to become off - network. The user may also be prevented from remaining networked indefinitely. In some embodiments, when the user becomes networked, a timer may be initialized. After the timer expires, the user may be made off - network. For example, after authentication and becoming networked, the user may have 8 hours (e.g., the second time period) before becoming off - network. The duration of the timer may be a tunable system parameter. After becoming off - network, the user may re - authenticate themselves to become networked again.

[0091] Figure 5 An example use case of using a trust token for a transaction is shown. In this example, the trust token is used to keep the user logged into the banking application.

[0092] In step S1, the second user device 504 (e.g., a wearable device including hardware and software for detecting a heartbeat,) synchronizes with the security application 502A executed on the first user device. The second user device 504 and the security application 502A may synchronize by substantially simultaneously determining user activity (e.g., by sending an indication that the user has been authenticated and detected within a time period of several seconds). In this example, the first user device is a mobile device and may be substantially similar to the user device 300 described above with respect to Figure 3 The security application 502A is a banking application (e.g., as Figure 5 shown, for KBB Bank) and may be substantially similar to the security application 312 described above with respect to Figure 3

[0093] ​The first user device 502 can receive user login information from the user via the interface element 502B of the security application 502A. The first user device 502 can send the login information to the remote entity computer 512 associated with the security application 502A (for example, the entity computer 512 can be the server computer of a bank that provides the security application 502A). The entity computer 512 can send an authentication confirmation to the first user device 502. The first user device 502 can in turn send a signal indicating that the user has been authenticated to the server computer 506 in step S2.

[0094] The server computer 506 can be generally similar to the server computer 200 described above with respect to Figure 2 The synchronization between the second user device 504 and the security application 502A can be performed via the server computer 506. For example, the second user device 504 and the security application 502A can each send a signal to the server computer 506 waiting for a reply, and synchronization may occur on the server computer 506. The server computer can use a record (for example, Figure 1 the record 106A) to represent this synchronization.

[0095] In step S2, the server computer 506 issues a trust token 510 and stores the trust token 510 in the data store 508 in response to receiving a signal indicating that the user has been authenticated and detected. The data store 508 can be a cloud storage system (for example, "the cloud"), and can be generally similar to the data store 220 described above with respect to Figure 2 The trust token 510 can be generally similar to the trust token 222 described above with respect to Figure 2 The trust token 510 can be generated based on the detection of a positive record, as described above with respect to Figure 1 Alternatively or additionally, the trust token 222 can be generated based on determining that the user has accessed the network. For example, as a precursor to generating the trust token 222, the server computer 506 can use the digital identity platform described above with respect to Figure 4 to determine that the user has accessed the network. The trust token 222 can also be generated based on detecting the user via a wearable device. The continuous detection of the user via the second user device 504 can enable the trust token 222 to be maintained over time.

[0096] In step S3, the trust token 510 in the cloud is used to determine whether to grant a user access to a resource. The trust token 510 can improve the user experience. For example, the user can be permitted to initiate a fund transfer via the secure application 502A without having to re-authenticate themselves or enter their payment credentials. For example, the trust token 510 can be used to avoid the user having to authenticate themselves by entering information such as a one-time password. The trust token 510, in combination with a digital identity, can advantageously be used to avoid the need to enter sensitive data such as personally identifiable information.

[0097] Figure 6 FIG. shows a flowchart of a method 600 for using a trust token to control access to a resource according to some embodiments. The operations may be performed by the system described above - specifically, the server computer Figures 1 - 3 described. Figure 6 of.

[0098] In step 602, the server computer may receive an indication that the user has been authenticated from a first application on the user device. The first application and / or a remote entity computer associated with the first application may authenticate the user, for example, by accepting and verifying the user's login credentials. The login credentials may be supplemented, for example, via metadata on the user device and / or an additional authentication layer for progressive authentication. Alternatively or additionally, the first application may forward an indication that the user is being authenticated received from an external access device. For example, when first entering a secure facility, the user may scan their mobile phone and two forms of identification into the access device. The access device may authenticate the user in combination with the connected physical device and send a notification of the authenticated user to the first application. In any case, the server computer may receive an indication that the user has been authenticated by a message sent over the network to the server computer. The message may further include a timestamp indicating the time at which the user was authenticated.

[0099] In step 604, the server computer may receive an indication that the user has been detected from a second application executing on the user device. The user device may receive an indication that the user has been detected from a wearable device on the user. For example, the user device may communicate with a wearable device (e.g., Figure 1 the second user device 104) worn by the user. The wearable device may detect the heartbeat and continuously or periodically notify an application on the user device (e.g., Figure 1 the second application 102B) that the user's heartbeat has been detected. The wearable device may be used to ensure that the user is alive and well and is wearing the wearable device in a substantially continuous manner.

[0100] In some embodiments, as an enhanced security measure, a wearable device and / or an associated application on a user device may analyze a detected heartbeat. For example, the user device may analyze the pattern and persistence of the heartbeat based on historical data collected in association with the user's heartbeat to ensure that it matches the pattern and persistence of the heartbeat of an authorized user. The historical data may correspond to the stored heartbeat of the user. The system may perform a comparison between such stored user heartbeat and the detected heartbeat. The user device may analyze the characteristics of the stored and detected heartbeat data to determine whether the user has woken up, and / or whether the detected heartbeat includes a characteristic pattern associated with the user. Determining that the user has woken up may be an additional prerequisite before indicating that the user has been detected. Alternatively or additionally, the user may be detected based on pulse, touch, video recording, etc. In any case, the server computer may receive an indication that the user has been detected by a message sent over the network to the server computer. The message may further include a timestamp indicating the time at which the user was detected.

[0101] In step 606, the server computer may determine whether the indications of steps 602 and 604 have been received within a threshold time period. The server computer may compare the timestamp indicating the time at which the user was authenticated with the timestamp indicating the time at which the user was detected (e.g., by subtracting the two timestamps to identify the time period elapsed between receiving the two indications). The server computer may identify a predetermined threshold time period. The server computer may store threshold time periods for different contexts. For example, the server computer may store threshold time periods for generating trust tokens, for maintaining trust tokens, and / or for different entities (e.g., a banking application may require a shorter time window than a merchant application). For the purpose of generating a trust token, the threshold time period may be, for example, 1 second. If the difference between the timestamps is less than or equal to the threshold, the server computer may determine that the indications of steps 602 and 604 have been received within the threshold time period ("yes" result). If the difference between the timestamps is greater than the threshold, the server computer may determine that the indications of steps 602 and 604 have not been received within the threshold time period ("no" result).

[0102] If the indication has not been received within the threshold time period, the server computer may avoid generating a trust token and the process may end. If the indication has been received within the threshold time period, the process may optionally proceed to step 608, or alternatively, directly proceed to step 610.

[0103] In step 608, the server computer may optionally determine whether the user is networked (e.g., whether the user's digital identity is open). The server computer may identify whether the user is networked based on records stored to the digital identity platform, as described above with respect to Figure 4As described. Going online can indicate that the user has authorized access to user data associated with the user's digital identity. In some cases, the user can authorize this access for a period of time (e.g., by being "online" for a day). The user can go "offline" by revoking access to user data associated with the user's digital identity. If the user goes online, the process can proceed to step 610. If the user does not go online, the process can end.

[0104] In step 610, the server computer can generate a trust token for the user. The server computer can generate the trust token based on indications received at steps 602 and 604 within a threshold time period. For example, if the user's heartbeat is detected within ten seconds of the user authenticating via the first application, a trust token can be issued. The server computer can use the stored records to determine whether to generate a trust token, as described above with respect to Figure 1 As described.

[0105] In step 612, the server computer can continuously or periodically determine whether the conditions for maintaining the trust token for the user are met. For example, it can be determined in a manner similar to determining whether to generate a trust token - e.g., by repeating steps 604 - 608, to perform the determination of whether to maintain the trust token. In addition to the initial indications for generating the trust token, the user device can also periodically send additional indications to the server computer that the user has been detected (or not detected). The additional indications can be used to determine whether to maintain the trust token. For example, the server computer can receive an indication from the user device that the user is detected once every 30 seconds and update the record based on the indication. Updating the record can include changing the record, avoiding changing the record, or changing the record to indicate that the heartbeat has been detected or not detected within a specific time.

[0106] The server computer can determine to maintain the trust token based on indications received at steps 602 and 604 within a threshold time period. The threshold time period for maintaining the trust token can be different from the threshold time period for generating the trust token. For example, if the user's heartbeat is detected within four hours of the user authenticating via the first application, the server computer can determine that the conditions for maintaining the trust token are met, while the threshold time period for generating the trust token may be much shorter. The server computer can use the stored records to determine whether the conditions for maintaining the trust token are met, as described above with respect to Figure 1As described. The conditions for maintaining the trust token can be further based on whether the user is networked, as described above with respect to step 608. Thus, the server computer can maintain the trust token based on determining that the user has granted access to the user's digital identity, or revoke the trust token based on determining that the user has revoked access to the user's digital identity. If the time period associated with remaining networked has passed, the server computer can further revoke the trust token.

[0107] In step 614, the server computer can maintain the trust token. The server computer can maintain the trust token based on determining "yes" in step 612. Maintaining the trust token can include not revoking the trust token. Alternatively or additionally, maintaining the trust token can involve actively updating the trust token status (e.g., updating to an active state since a specific time).

[0108] In step 616, the server computer can revoke the trust token. The server computer can revoke the trust token based on determining "no" in step 612. Revoking the trust token can include deleting the trust token. Alternatively, revoking the trust token can involve updating the trust token status (e.g., updating to a non-active state since a specific time). For example, the server computer can receive an indication that the user has not been detected from a second application on the user device. The user may have removed the wearable device, separated the wearable device from the user device for too long a period, or even died. Based on receiving the indication that the user has not been detected, the server computer can revoke the trust token.

[0109] In step 618, the server computer can identify or permit an entity computer to identify the trust token. The trust token can be identified based on a request to access a resource. For example, a user can attempt to make a purchase, transfer funds, stay logged into a secure website or application, access a secure location, etc. via an application on the user device and / or the entity computer. Accessing the resource may require authenticating the user. Thus, it is determined whether the trust token is in a valid state so that the user can remain authenticated via the trust token. In some embodiments, the entity can send an authentication request message to the server computer, and the server computer can retrieve the trust token based on the information in the authentication request message. Alternatively or additionally, the server computer can allow the entity to access the trust token. For example, the server computer can grant the entity access to a cryptographic key that the entity can use to retrieve the trust token. In some embodiments, identifying the trust token can include identifying the user's digital identity, where the trust token is stored in association with the user's digital identity.

[0110] A server computer and / or an entity computer can analyze the identified trust token to determine whether the trust token is valid. If the trust token exists in the cloud, the trust token may be valid; if the trust token does not exist in the cloud, the trust token may be invalid. Alternatively or additionally, if the trust token has a specific value (e.g., valid or 1), the trust token may be valid; if the trust token has another value (e.g., invalid or 0), the trust token may be invalid.

[0111] In step 620, access to the resource can be granted based on the identified valid trust token in step 618. The trust token can be used to ensure the entity that the user is authenticated and behaves normally, i.e., remains authenticated. The entity computer can grant access to the requested resource based on the valid trust token. For example, the entity computer can allow the user to transfer funds, purchase goods and services, enter a secure location, etc.

[0112] As an example, access to the resource can be granted by an entity associated with the application that initially authenticated the user. This is somewhat similar to the case of using a cookie to extend the user's login. However, in this case, the trust token is more secure and can be used to grant access based on the initial authentication for a longer period of time. The user can authenticate to log in to a bank website. As long as the trust token remains valid (e.g., as long as the user's heartbeat is detected by the wearable device), the user can remain logged in, thus avoiding the need for re-authentication.

[0113] As another example, access can be granted by one or more entities different from the application that initially authenticated the user. For example, based on the authentication information retrieved from a trusted application (e.g., a secure banking application) and a generally continuous heart rate confirmation, different entities can grant the user access to the resource. The different entities can be (for example) a social media application, a merchant website, etc. As long as the trust token remains valid, multiple different entities can grant the user access to the resource. The user's digital identity can be used to manage different entities and resources. The digital identity can be used to manage events associated with the user. With this detailed information about the user, the system can identify the resources that the user can access with a valid trust token.

[0114] As another example, access to a transportation service can be granted based on the trust token. The user can purchase a weekly subway pass and, when initially using the pass to take the subway, scan an identifier to authenticate themselves in combination with the pass. As long as the user's wearable device detects the user, they can use the trust token to enter the subway system again.

[0115] In some embodiments, a trust token may grant access to a resource in limited circumstances. For example, a trust token may allow a user to make a purchase without further input for transactions up to $100. If the transaction amount exceeds $100, additional information may be prompted from the user. The trust token may be stored associated with configuration data (e.g., currency limit or time limit) to enforce such limits. As another example, a trust token may allow a user to gain access to a secure facility for 24 hours. After 24 hours, the trust token is revoked and the user must re-authenticate.

[0116] In step 622, escalation or denial may be performed based on the non-detection of a valid trust token at step S618. For example, if the trust token has been revoked, the user may be prompted to log in again or escalated via a confirmation of a code number sent to the user. Alternatively or additionally, access to the resource may be denied (e.g., in the case where the user fails the escalation authentication).

[0117] The embodiments provide several advantages. By limiting the number of times a user must re-verify to access one or more resources, the hassle to the user can be reduced. Additionally, the use of trust tokens can facilitate a secure way of determining when access should be granted. Unlike cookies which are easily tampered with, trust tokens can be managed to prevent tampering. For example, a trust token may be password-protected and only accessible by trusted entities under controlled conditions. Additionally, the use of trust tokens and digital identities can be used to grant users access to resources without disclosing the user's personally identifiable information, thereby protecting user privacy.

[0118] Using trust tokens to maintain authentication can further reduce the time required to process resources and determine whether to grant access to a resource. The user does not need to repeatedly log in or escalate, thereby eliminating or significantly reducing the messaging and processing required to perform such functions. Additionally, compared to some prior techniques that extend user authentication, maintaining trust tokens can have lower processing requirements. By monitoring the user via a single biometric parameter (e.g., heart rate), the state of the trust token can be managed with a simple data set. This can reduce the computational power required to determine whether to grant access to a resource (e.g., compared to tracking user behavior which can be rather complex).

[0119] Any software component or functionality described in this application can be implemented as software code executed by a processor using any suitable computer language, such as Java, C++, or Perl, which may use, for example, object-oriented techniques. The software code can be stored as a series of instructions or commands on a computer-readable medium, such as random access memory (RAM), read-only memory (ROM), magnetic media such as a hard disk drive or floppy disk, or optical media such as a CD-ROM. Any such computer-readable medium can reside on or within a single computing device and can exist on or within different computing devices in a system or network.

[0120] The above description is illustrative and not restrictive. Many variations of the invention will be apparent to those skilled in the art upon review of this disclosure. Accordingly, the scope of the invention is not to be determined by reference to the above description, but instead is to be determined by reference to the pending claims and their full scope or equivalents.

[0121] Without departing from the scope of the invention, one or more features of any embodiment may be combined with one or more features of any other embodiment.

[0122] Unless clearly indicated to the contrary, the recitation of "a" or "the" is intended to mean "one or more."

[0123] All patents, patent applications, publications, and descriptions mentioned above are incorporated by reference in their entirety for all purposes. They are not admitted to be prior art.

Claims

1. A method, comprising: receiving, by a server computer, an indication that a user has been authenticated from a first application on a user device; receiving, by the server computer, an indication that the user has been detected from a second application on the user device, wherein the user device receives the indication that the user has been detected from a wearable device on the user; determining, by the server computer, that the user has authorized access to user data associated with the user's digital identity, wherein the user data associated with the user's digital identity includes one or more of a date of birth, a social security number, or an address; generating or maintaining, for the user, a trust token based on receiving two of the indications within a period of time and determining that the user has authorized access to the user data associated with the user's digital identity, wherein the trust token is stored in association with the user's digital identity and is used to extend the period of time the user remains authenticated to a security system; receiving, by the server computer, an indication that the user has not been detected from the second application on the user device; revoking the trust token based on receiving the indication that the user has not been detected; generating, for the user, a second trust token based at least on receiving a second indication that the user has been authenticated and a second indication that the user has been detected; determining, by the server computer, that the user has revoked access to the user data associated with the user's digital identity; and revoking, by the server computer, the second trust token based on determining that the user has revoked the access.

2. The method according to claim 1, wherein the period of time is a first period of time, and wherein the user has authorized access to the user data associated with the user's digital identity within a second period of time, the method further comprising: generating, by the server computer, a third trust token for the user based at least on receiving a third indication that the user has been authenticated and a third indication that the user has been detected; determining, by the server computer, that the second period of time has expired; and revoking, by the server computer, the third trust token based on determining that the second period of time has expired.

3. The method according to claim 1, further comprising: identifying, by the server computer, the user's digital identity.

4. The method according to claim 1, further comprising: periodically updating, by the server computer, a record based on periodically received indications that the user has been detected, wherein the trust token is maintained based on the record.

5. The method according to claim 1, wherein: the indication that the user has been detected corresponds to the user's detected heartbeat.

6. The method according to claim 5, further comprising: comparing, by the server computer, the user's detected heartbeat with the user's stored heartbeat; and Based on the comparison, the server computer determines that the detected heartbeat matches the stored heartbeat, and a trust token is further generated or maintained based on determining that the detected heartbeat matches the stored heartbeat.

7. A server computer, comprising: a processor; and a computer-readable medium operatively coupled to the processor for performing a method comprising the following: Receiving an indication that the user has been authenticated from a first application on a user device; Receiving an indication that the user has been detected from a second application on the user device, wherein the user device receives the indication that the user has been detected from a wearable device on the user; Determining that the user has authorized access to user data associated with the user's digital identity, wherein the user data associated with the user's digital identity includes one or more of date of birth, social security number, or address; Generating or maintaining a trust token for the user based on receiving two such indications within a time period and determining that the user has authorized access to the user data associated with the user's digital identity, wherein the trust token is stored in association with the user's digital identity and is used to extend the time period during which the user remains authenticated to a security system; Receiving an indication that the user has not been detected from the second application on the user device; Revoking the trust token based on receiving the indication that the user has not been detected; Generating a second trust token for the user at least based on receiving a second indication that the user has been authenticated and a second indication that the user has been detected; Determining that the user has revoked access to the user data associated with the user's digital identity; and Revoking the second trust token based on determining that the user has revoked the access.

8. The server computer according to claim 7, wherein the time period is a first time period, and wherein the user has authorized access to the user data associated with the user's digital identity within a second time period, the method further comprising: Generating a third trust token for the user by the server computer at least based on receiving a third indication that the user has been authenticated and a third indication that the user has been detected; Determining by the server computer that the second time period has expired; and Revoking the third trust token by the server computer based on determining that the second time period has expired.

9. The server computer according to claim 7, wherein the trust token is stored in association with the user's digital identity.

10. The server computer according to claim 7, the method further comprising: Periodically updating a record based on the periodically received indication that the user has been detected, wherein the trust token is maintained based on the record.

11. The server computer according to claim 7, wherein the indication that the user has been detected corresponds to the detected heartbeat of the user; the method further comprising: Compare the detected heartbeat of the user with the stored heartbeat of the user; and Based on the comparison, determine that the detected heartbeat matches the stored heartbeat, wherein based on determining that the detected heartbeat matches the stored heartbeat, a trust token is further generated or maintained.

12. A method, comprising: Determine by a user device that a user has been authenticated; Send an indication that the user has been authenticated from the user device to a server computer; Determine by the user device that the user is detected, wherein the user device determines that the user is detected based on information generated by a wearable device based on detecting the user's heartbeat; Send an indication that the user is detected from the user device to the server computer, wherein the server computer determines that the user has authorized access to user data associated with the digital identity of the user, wherein the user data associated with the digital identity of the user includes one or more of a date of birth, a social security number, or an address, and the server computer generates or maintains a trust token for the user based on receiving two such indications within a period of time and determining that the user has authorized access to the user data associated with the digital identity of the user, wherein the trust token is stored in association with the digital identity of the user and is used to extend the period of time the user remains authenticated to a security system; Receive from the wearable device an indication that the user is not detected by the user device; and Send the indication that the user is not detected from the user device to the server computer, wherein the trust token is revoked based on the indication that the user is not detected, wherein the server computer then generates a second trust token for the user, determines that the user has revoked access to the user data associated with the digital identity of the user, and revokes the second trust token based on determining that the user has revoked the access.

13. The method according to claim 12, further comprising: Periodically send from the user device an additional indication that the user is detected to the server computer, wherein the additional indication is used to maintain the trust token.

14. A user device, comprising: A processor; and A computer-readable medium operatively coupled to the processor for performing a method comprising: Determine that a user has been authenticated; Send an indication that the user has been authenticated to a server computer; Determine that the user is detected, wherein the user device determines that the user is detected based on information generated by a wearable device based on detecting the user's heartbeat; and Send an indication that the user is detected to the server computer, The server computer determines that the user has authorized access to user data associated with the user's digital identity, where the user data associated with the user's digital identity includes one or more of date of birth, social security number, or address, and the server computer generates or maintains a trust token for the user based on receiving two such indications within a period of time and determining that the user has authorized access to the user data associated with the user's digital identity, where the trust token is stored in association with the user's digital identity and is used to extend the period during which the user remains authenticated to the security system; Receiving, from the wearable device, an indication that the user has not been detected; And Sending the indication that the user has not been detected to the server computer, where the trust token is revoked based on the indication that the user has not been detected, Where the server computer then generates a second trust token for the user, determines that the user has revoked access to the user data associated with the user's digital identity, and revokes the second trust token based on determining that the user has revoked the access.

15. The user device according to claim 14, the method further Comprising: Periodically sending additional indications that the user has been detected to the server computer, where the additional indications are used to maintain the trust token.

Images