EP4690658A1

EP4690658A1 - Continuous token control

Info

Publication number: EP4690658A1
Application number: EP23932278.7A
Authority: EP
Inventors: Eric Le Saint
Original assignee: Visa International Service Association
Current assignee: Visa International Service Association
Priority date: 2023-04-04
Filing date: 2023-04-04
Publication date: 2026-02-11
Also published as: WO2024210935A1; CN120898400A

Abstract

Systems and methods are disclosed herein for continuous token monitoring and control, in one example comprising receiving, by a credentialing agent, a token protection request from a client, to generate a time code for the token to allow client access to a service of a provider; receiving, by the credentialing agent, at least one of risk data, a time code model, or secret parameters associated with the token; generating, by the credentialing agent, an ETA model, based on at least one of the risk data, the time code model, or the secret parameters; cryptographically binding, by the credentialing agent, the token, the risk data and the ETA model to generate a time code; and transmitting, the time code to at least one of the client, provider, or a provider credentialing service, to facilitate a validation of the time code and the token to allow the client access to the service.

Description

TITLE

CONTINUOUS TOKEN CONTROL

TECHNICAL FIELD

[0001] The present technology pertains to systems and methods for securing access to web services, servers, online platforms and gateways. The systems and methods included herein are designed to monitor and control token issuance, authentication, and validation to access a variety of services online. In particular, but not by way of limitation, the present technology provides systems and methods for continuous token protection and control.

SUMMARY

[0002] In numerous aspects the present disclosure provides a computer implemented method for continuous token monitoring and control, comprising receiving, by a credentialing agent, a token protection request from a client, to generate a time code for the token to allow client access to a service of a provider; receiving, by the credentialing agent, at least one of risk data, a time code model, or secret parameters associated with the token; generating, by the credentialing agent, an estimated time of arrival (ETA) model, based on at least one of the risk data, the time code model, or the secret parameters, wherein the ETA model determines an ETA of the token to the provider; cryptographically binding, by the credentialing agent, the token, the risk data and the ETA model to generate a time code; and transmitting, the time code to at least one of the client, the provider, or a provider credentialing service, to facilitate a validation of the time code and the token to allow the client access to the service.

[0003] In numerous aspects the computer implemented method, the ETA model is a token validity time window.

[0004] In several aspects, the computer implemented method, further comprises monitoring, by the credentialing agent, the risk data, during the token validity time window, wherein the monitoring can take into account new factors or events that adjust the risk data.

[0005] In several aspects the computer implemented method, further comprises determining, by the credentialing agent, based on the monitoring, that the risk data meets or exceeds a risk threshold; and invalidating, by the credentialing agent, at least one of the token, the risk data, the ETA model, or the time code.

[0006] In various aspects the computer implemented method, further comprises determining, by the credentialing agent, based on the monitoring, that a risk score does not reach a risk threshold.

[0007] In multiple aspects, the computer implemented method, further comprises extending the token validity time window by the credentialing agent.

[0008] In many aspects, in the computer implemented method, the ETA model is calculated using a service clock of the time code model.

[0009] In numerous aspects in the computer implemented method, the time code is verified by the service, the provider, a provider service gateway web server, a Transport Layer Security, or a provider credentialing service, to access the token.

[0010] In various aspects, in the computer implemented method, the credentialing agent is associated to the client.

[0011] In numerous aspects, in the computer implemented method, the risk data meets or exceeds a threshold, preventing the generating of a time code.

[0012] In numerous aspects the present disclosure provides a system for continuous token monitoring and control, the system comprising a provider that provides a web service; a credentialing service, associated to the provider, to manage service requests to the web service; a client, running on a user device, that requests access to the web service; and a credentialing agent, associated to the client, the credentialing agent configured to receive, a token protection request from the client, to generate a time code for the token to allow client access to a service of a provider; receive, at least one of risk data, a time code model, or secret parameters associated with the token; generate, an ETA model, based on at least one of the risk data, the time code model, or the secret parameters, wherein the ETA model determines an ETA of the token to the provider; cryptographically bind the token, the risk data and the ETA model to generate a time code; and transmit, the time code to at least one of the client, the provider, the web service, or a provider credentialing service.

[0013] In various aspects, in the system, the credentialing agent is further configured to receive token protection data that originated from the credentialing service, based on the token and an identifier of the web service.

[0014] In various aspects, in the system, at least one of the credentialing agent or the client is further configured to register the token protection data for further use.

[0015] In various aspects, in the system, the token protection data comprises at least one of a remote clock, a time code model, a signing policy, a token signing certificate, a token validation service address, or secret parameters.

[0016] In various aspects, the system further comprises a token issuance service, configured to receive a service access request from the client to access the web service; authenticate the client; generate the token upon successful authentication; and transmit the token to the client.

[0017] In various aspects, in the system, the client is configured to request access to the web service from at least one of a token issuance service, the provider, or the web service; receive the token from at least one of a token issuance service, the provider, or the web service; register the token; and request token protection from the credentialing agent.

[0018] In various aspects, in the system, the credentialing agent is at least one of an isolated enclave, a container, a cloud based app, or a computing device app.

[0019] In various aspects, in the system, the provider comprises a gateway web server.

[0020] In various aspects, in the system, the client is configured to: add the time code to an HTTP header and transmit a request comprising the HTTP header and the time code to at least one of the credentialing service, the provider, or the web service.

[0021] In numerous aspects the present disclosure provides a computer implemented method for authenticating a received token, comprising receiving, by at least one of a provider of a service, the service, a credentialing service, a provider gateway, a provider web server, or a security stack, a request comprising a time code comprising a token and an HTTP header from a client; extracting, by the security stack, the time code from the request; validating the time code by the security stack; and based on the validating, processing, by at least one of the provider gateway, the provider web server, or the security stack, the token from the time code; and processing, by the service, the request to allow a client access to the service.

BRIEF DESCRIPTION OF THE DRAWINGS

[0022] In the description, for purposes of explanation and not limitation, specific details are set forth, such as particular aspects, procedures, techniques, etc. to provide a thorough understanding of the present technology. However, it will be apparent to one skilled in the art that the present technology may be practiced in other aspects that depart from these specific details.

[0023] The accompanying drawings, where like reference numerals refer to identical or functionally similar elements throughout the separate views, together with the detailed description below, are incorporated in and form part of the specification, and serve to further illustrate aspects of concepts that include the claimed disclosure and explain various principles and advantages of those aspects.

[0024] The systems and methods disclosed herein have been represented where appropriate by conventional symbols in the drawings, showing only those specific details that are pertinent to understanding the various aspects of the present disclosure so as not to obscure the disclosure with details that will be readily apparent to those of ordinary skill in the art having the benefit of the description herein.

[0025] FIG. 1 illustrates a traditional token-based service access model, according to at least one aspect of the present disclosure.

[0026] FIG. 2 illustrates a simplified diagram of a system for continuous token control, according to at least one aspect of the present disclosure.

[0027] FIG. 3 illustrates a flow-diagram of a method for continuous token protection and control, according to at least one aspect of the present disclosure.

[0028] FIG. 4 illustrates a state of a system at one phase of token protection and control, according to at least one aspect of the present disclosure.

[0029] FIG. 5 illustrates a state of a system at another phase of token protection and control, according to at least one aspect of the present disclosure.

[0030] FIG. 6 illustrates a framework to measuring or determining an ETA model for a token within a system of token protection and control, according to at least one aspect of the present disclosure.

[0031] FIG. 7 illustrates a cryptographic binding of various components to generate a timecode, according to at least one aspect of the present disclosure.

[0032] FIG. 8 presents a block diagram of a computer apparatus, according to at least aspect of the present disclosure.

[0033] FIG. 9 is a diagrammatic representation of an example system that includes a host machine within which a set of instructions to perform any one or more of the methodologies discussed herein may be executed.

DESCRIPTION

[0034] The following disclosure may provide exemplary systems, devices, and methods for conducting secure access to web services, financial transactions and related activities. Although reference may be made to such financial transactions in the examples provided below, aspects are not so limited. That is, the systems, methods, and apparatuses may be utilized for any suitable purpose.

[0035] Before discussing specific embodiments, aspects, or examples, some descriptions of terms used herein are provided below.

[0036] An “application” may include any software module configured to perform a specific function or functions when executed by a processor of a computer. For example, a “mobile application” may include a software module that is configured to be operated by a mobile device. Applications may be configured to perform many different functions. For instance, a “payment application” may include a software module that is configured to store and provide account credentials for a transaction. A “wallet application” may include a software module with similar functionality to a payment application that has multiple accounts provisioned or enrolled such that they are usable through the wallet application. Further, an “application” or “application program interface” (API) refers to computer code or other data sorted on a computer-readable medium that may be executed by a processor to facilitate the interaction between software components, such as a client-side front-end and/or server-side back-end for receiving data from the client.

[0037] “Authentication” is a process by which the credential of an endpoint (including but not limited to applications, people, devices, process, and systems) can be verified to ensure that the endpoint is who they are declared to be.

[0038] The terms “client device” and “user device” refer to any electronic device that is configured to communicate with one or more servers or remote devices and/or systems. A client device or a user device may include a mobile device, a network-enabled appliance (e.g., a network-enabled television, refrigerator, thermostat, and/or the like), a computer, a POS system, and/or any other device or system capable of communicating with a network. A client device may further include a desktop computer, laptop computer, mobile computer (e.g., smartphone), a wearable computer (e.g., a watch, pair of glasses, lens, clothing, and/or the like), a cellular phone, a network-enabled appliance (e.g., a network-enabled television, refrigerator, thermostat, and/or the like), a point of sale (POS) system, and/or any other device, system, and/or software application configured to communicate with a remote device or system.

[0039] As used herein, the term “communication” and “communicate” may refer to the reception, receipt, transmission, transfer, provision, and/or the like of information (e.g., data, signals, messages, instructions, calls, commands, and/or the like). A communication may use a direct or indirect connection and may be wired and/or wireless in nature. As an example, for one unit (e.g., a device, a system, a component of a device or system, combinations thereof, and/or the like) to communicate with another unit means that the one unit is able to directly or indirectly receive information from and/or transmit information to the other unit. The one unit may communicate with the other unit even though the information may be modified, processed, relayed, and/or routed between the one unit and the other unit. In one example, a first unit may communicate with a second unit even though the first unit receives information and does not communicate information to the second unit. For example, a first unit may be in communication with a second unit even though the first unit passively receives data and does not actively transmit data to the second unit. As another example, a first unit may communicate with a second unit if an intermediary unit (e.g., a third unit located between the first unit and the second unit) receives information from the first unit, processes the information received from the first unit to produce processed information, and communicates the processed information to the second unit. In some non-limiting embodiments or aspects, a message may refer to a packet (e.g., a data packet, a network packet, and/or the like) that includes data. It will be appreciated that numerous other arrangements are possible.

[0040] A “communication channel” may refer to any suitable path for communication between two or more entities. Suitable communications channels may be present directly between two entities such as a payment processing network and a merchant or issuer computer, or may include a number of different entities. Any suitable communications protocols may be used for generating a communications channel. A communication channel may in some instances comprise a “secure communication channel” or a “tunnel,” either of which may be established in any known manner, including the use of mutual authentication and a session key and establishment of a secure communications session. However, any method of creating a secure communication channel may be used, and communication channels may be wired or wireless, as well as long-range, short-range, or medium-range. By establishing a secure channel, sensitive information related to a payment device (such as account number, card verification values (CVVs), expiration dates, etc.) may be securely transmitted between the two entities to facilitate a transaction

[0041] As used herein, the term “computing device” or “computer device” may refer to one or more electronic devices that are configured to directly or indirectly communicate with or over one or more networks. A computing device may be a mobile device, a desktop computer, and/or the like. As an example, a mobile device may include a cellular phone (e.g., a smartphone or standard cellular phone), a portable computer, a wearable device (e.g., watches, glasses, lenses, clothing, and/or the like), a personal digital assistant (PDA), and/or other like devices. The computing device may not be a mobile device, such as a desktop computer. Furthermore, the term “computer” may refer to any computing device that includes the necessary components to send, receive, process, and/or output data, and normally includes a display device, a processor, a memory, an input device, a network interface, and/or the like.

[0042] A “cryptographic algorithm” can be an encryption algorithm that transforms original data into an alternate representation, or a decryption algorithm that transforms encrypted information back to the original data. Examples of cryptographic algorithms may include triple data encryption standard (TDES), data encryption standard (DES), advanced encryption standard (AES), etc. Encryption techniques may include symmetric and asymmetric encryption techniques.

[0043] A “frequency of use” of a token may indicate how many times a token can be used in a transaction. For example, a frequency of use may indicate how many times a token may successfully be used in a payment transaction. For example, a token may include a frequency of use of single-use or multiple-use. A single-use token may be used to generate one transaction. After the first-use of the single-use token, any subsequent use for initiating a transaction can be deemed invalid and a subsequent transaction may be denied. A multi-use token can be used to initiate multiple transactions.

[0044] A “key” may refer to a piece of information that is used in a cryptographic algorithm to transform input data into another representation. An exemplary encryption key may include a master derivation key (MDK) which may be used to generate a limited use key (LUK) that is provided to a computer device of a user. An LUK can be an encryption key that is intended for limited use (e.g., a limited number of transactions or a limited time period) and is not intended to be used for the lifetime of an account. Further details regarding LUKs can be found in U.S. Published Patent Application No. 2015/0180836, which is herein incorporated by reference in its entirety and is assigned to the same assignee as the present application. The MDK may be used to generate and provision the token, as well as, authenticate the token when used in authorization processing by validating static and variable transaction data.

[0045] As used herein, the term “payment gateway” may refer to an entity and/or a payment processing system operated by or on behalf of such an entity (e.g., a merchant service provider, a payment service provider, a payment facilitator, a payment facilitator that contracts with an acquirer, a payment aggregator, and/or the like), which provides payment services (e.g., transaction service provider payment services, payment processing services, and/or the like) to one or more merchants. The payment services may be associated with the use of portable financial devices managed by a transaction service provider. As used herein, the term “payment gateway system” may refer to one or more computer systems, computer devices, servers, groups of servers, and/or the like, operated by or on behalf of a payment gateway and/or to a payment gateway itself. The term “payment gateway mobile application” may refer to one or more electronic devices and/or one or more software applications configured to provide payment services for transactions (e.g., payment transactions, electronic payment transactions, and/or the like).

[0046] A “requestor” may be an entity that can request an item or action. A requestor may be an application, a device, or a system that is configured to perform actions associated with tokens. For example, a requestor can request registration with a network token system, request token generation, token activation, token de-activation, token exchange, and other token life-cycle management related processes, and/or any other token related processes. A requestor may interface with a network token system through any suitable communication networks and/or protocols (e.g., using HTTPS, simple object access protocol (SOAP) and/or an extensible markup language (XML) interface). Some non-limiting examples of a requestor may include third party wallet providers, issuers, acquirers, merchants, and/or payment processing networks.

[0047] A requestor may be referred to as a “service requester/requestor” when requesting generation of a new token or requesting a new use of an existing token from a network token system. In some embodiments or aspects, a service requester can request tokens for multiple domains and/or channels. Some non-limiting examples of service requestor requestors may include, for example, card-on-file merchants, acquirers, acquirer processors, and payment gateways acting on behalf of merchants, payment enablers (e.g., original equipment manufacturers, mobile network operators, etc.), digital wallet providers, issuers, third party wallet providers, and/or payment processing networks. A service requestor may refer to an entity that is seeking to implement tokenization according to embodiments or aspects of the present disclosure. The token requestor may initiate a request that a primary account number (PAN) be tokenized by submitting a token request message to the service provider. According to various embodiments or aspects discussed herein, a service requestor may no longer need to store a PAN associated with a token once the requestor have received the token in response to a token request message. A service requestor may be registered and identified uniquely by the service provider within the tokenization ecosystem.

[0048] As used herein, the term “server” may include one or more computing devices which can be individual, stand-alone machines located at the same or different locations, may be owned or operated by the same or different entities, and may further be one or more clusters of distributed computers or “virtual” machines housed within a datacenter. It should be understood and appreciated by a person of skill in the art that functions performed by one “server” can be spread across multiple disparate computing devices for various reasons. As used herein, a “server” is intended to refer to all such scenarios and should not be construed or limited to one specific configuration. Further, a server as described herein may, but need not, reside at (or be operated by) a merchant, a payment network, a financial institution, a healthcare provider, a social media provider, a government agency, or agents of any of the aforementioned entities. The term “server” may also refer to or include one or more processors or computers, storage devices, or similar computer arrangements that are operated by or facilitate communication and processing for multiple parties in a network environment, such as the Internet, although it will be appreciated that communication may be facilitated over one or more public or private network environments and that various other arrangements are possible. Further, multiple computers, e.g., servers, or other computerized devices, e.g., point-of-sale devices, directly or indirectly communicating in the network environment may constitute a “system,” such as a merchant's point-of-sale system. Reference to “a server” or “a processor,” as used herein, may refer to a previously-recited server and/or processor that is recited as performing a previous step or function, a different server and/or processor, and/or a combination of servers and/or processors. For example, as used in the specification and the claims, a first server and/or a first processor that is recited as performing a first step or function may refer to the same or different server and/or a processor recited as performing a second step or function.

[0049] A “token” or “payment token” may include an identifier for a payment account that is a substitute for an account identifier, such as a primary account number (PAN). For example, a token may include a series of numeric and/or alphanumeric characters that may be used as a substitute for an original account identifier. For example, a token “4900 0000 0000 0001” may be used in place of a PAN “41470900 0000 1234.” In some embodiments or aspects, a token may be “format preserving” and may have a numeric format that conforms to the account identifiers used in existing payment processing networks (e.g., ISO 8583 financial transaction message format). In some embodiments or aspects, a token may be used in place of a PAN to initiate, authorize, settle or resolve a payment transaction or represent the original credential in other systems where the original credential would typically be provided. In some embodiments or aspects, a token value may be generated such that the recovery of the original PAN or other account identifier from the token value may not be computationally derived. For example, a token may have a random association with a particular real PAN so that the real PAN is not computationally derivable from the token. A lookup table may be used to associate a real PAN and a corresponding random token. Further, in some embodiments or aspects, the token format may be configured to allow the entity receiving the token to identify it as a token and recognize the entity that issued the token.

[0050] In some embodiments or aspects, tokens may be device-specific such that each device associated with an account may be provisioned with a particular token. As such, if a transaction uses a token that is initiated by a different device than the device that the token was provisioned into, the transaction may be fraudulent. Accordingly, device information may be stored in the token vault and used to ensure that the device used in a transaction is associated with the token that is being used in the transaction. Additionally, because each token may be associated with a single device, one PAN or account may have multiple tokens associated with it, where each PAN may have a different token for the different devices that may be used to initiate a transaction associated with the PAN using a specific token. This provides additional security for transactions because network token systems have additional information to validate in order to control the use of sensitive information in a transaction processing system. A number of tokens can include a number of dynamic tokens that can be requested for the same account identifier (e.g., PAN) and/or same device at one time. In some embodiments or aspects, the number of tokens can be optionally provided to the token requestor at the time of a token generation request. In some embodiments or aspects, tokens may be provided with overlapping time to live (TTL) so that one or more tokens may be active at any given time.

[0051] In some embodiments or aspects, the token format may allow entities in the payment system to identify the issuer associated with the token. For example, the format of the token may include a token issuer identifier that allows an entity (e.g. the payment processing network) to identify an issuer of the token. For instance, the token issuer identifier may be associated with an issuer's BIN of the underlying PAN in order to support the existing payment flow. The token issuer identifier may be a different number than the issuer's BIN and may be static. For example, if the issuer's BIN for an issuer is 412345, the token issuer identifier may be a token BIN of 428325 and this number may be static for all tokens issued from or for that issuer. In some embodiments or aspects, the token issuer identifier range (e.g., issuer token BIN range) may have the same attributes as the associated issuer card range and can be included in an issuer identifier routing table (e.g., BIN routing table). The issuer identifier routing table may be provided to the relevant entities in the payment system (e.g., merchants and acquirers).

[0052] A “token request message” may be an electronic message for requesting a token. A token request message may include information usable for identifying a payment account or digital wallet, and/or information for generating a payment token. For example, a token request message may include payment credentials, mobile device identification information (e.g. a phone number or MSISDN), a digital wallet identifier, information identifying a tokenization service provider, a merchant identifier, a cryptogram, and/or any other suitable information. Information included in a token request message can be encrypted (e.g., with an issuer-specific key). In some embodiments or aspects, a token request message may be formatted as an authorization request message (e.g., an ISO 8583 message format). In some embodiments or aspects, the token request message may have a zero dollar amount in an authorization amount field. As another example, the token request message may include a flag or other indicator specifying that the message is a token request message.

[0053] A “token response message” may be a message that responds to a token request. A token response message may include an indication that a token request was approved or denied. A token response message may also include a payment token, mobile device identification information (e.g. a phone number or MSISDN), a digital wallet identifier, information identifying a tokenization service provider, a merchant identifier, a cryptogram, and/or any other suitable information. Information included in a token response message can be encrypted (e.g., with an issuer-specific key). In some embodiments or aspects, a token response message may be formatted as an authorization response message (e.g., an ISO 8583 message format). In some embodiments or aspects, the token response message may have a zero dollar amount in an authorization amount field. As another example, the token response message may include a flag or other indicator specifying that the message is a token response message.

[0054] A “token service provider” may refer to an entity including one or more server computers in a token service system that generates, processes and maintains tokens. The token service provider may include or be in communication with a token vault where the generated tokens are stored. Specifically, the token vault may maintain one-to-one mapping between a token and a PAN represented by the token. The token service provider may have the ability to set aside licensed BINs as token BINs to issue tokens for the PANs that may be submitted to the token service provider. Various entities of a tokenization ecosystem may assume the roles of the token service provider. For example, payment networks and issuers or their agents may become the token service provider by implementing the token services according to embodiments or aspects of the present disclosure. A token service provider may provide reports or data output to reporting tools regarding approved, pending, or declined token requests, including any assigned token requestor IDs. The token service provider may provide data output related to token-based transactions to reporting tools and applications and present the token and/or PAN as appropriate in the reporting output.

[0055] A “token vault” may refer to a repository that maintains established token-to-PAN mappings. According to various embodiments or aspects, the token vault may also maintain other attributes of the token requestor that may be determined at the time of registration and that may be used by the token service provider to apply domain restrictions or other controls during transaction processing. For example, the token vault may maintain one-to-one mapping between a token and an account identifying number represented by the token. The token vault may be a part of the token service system. In some embodiments or aspects, the token vault may be provided as a part of the token service provider. Alternatively, the token vault may be a remote repository accessible by the token service provider. Token vaults, due to the sensitive nature of the data mappings that are stored and managed in them, may be protected by strong underlying physical and logical security.

[0056] A “user” may include an individual. In some embodiments or aspects, a user may be associated with one or more personal accounts and/or mobile devices. The user may also be referred to as a cardholder, account holder, or consumer.

[0057] A “user device” is an electronic device that may be transported and/or operated by a user. A user device may provide remote communication capabilities to a network. The user device may be configured to transmit and receive data or communications to and from other devices. In some embodiments or aspects, the user device may be portable. Examples of user devices may include mobile phones (e.g., smart phones, cellular phones, etc.), PDAs, portable media players, wearable electronic devices (e.g. smart watches, fitness bands, ankle bracelets, rings, earrings, etc.), electronic reader devices, and portable computing devices (e.g., laptops, netbooks, ultrabooks, etc.). Examples of user devices may also include automobiles with remote communication capabilities.

[0058] “User information” may include any information that is associated with a user. For example, the user information may include a device identifier of a device that the user owns or operates and/or account credentials of an account that the user holds. A device identifier may include a unique identifier assigned to a user device that can later be used to verify the user device. In some embodiments or aspects, the device identifier may include a device fingerprint. The device fingerprint may an aggregation of device attributes. The device fingerprint may be generated by a software development kit (SDK) provided on the user device using, for example, a unique identifier assigned by the operating system, an International Mobile Station Equipment Identity (IMEI) number, operating system (OS) version, plug-in version, and the like.

[0059] Reference to “a device,” “a server,” “a processor,” and/or the like, as used herein, may refer to a previously-recited device, server, or processor that is recited as performing a previous step or function, a different server or processor, and/or a combination of servers and/or processors. For example, as used in the specification and the claims, a first server or a first processor that is recited as performing a first step or a first function may refer to the same or different server or the same or different processor recited as performing a second step or a second function.

[0060] Connections and communications between clients and servers can include various potential vulnerabilities that allow malicious actors to insert malicious code, to disrupt the communications, discover vulnerabilities, and via one or more attack vectors obtain unauthorized information, assets, or other secrets. Clients may include for example web browsers, applications, payment applications, or wallets on user or computing devices. Servers may include for example service and/or web-service providers (“providers”). Tokens are one way to secure communications and requests from clients to servers or providers. Typically when clients and providers communicate or initiate a communication or transaction, for example a payment transaction, before the client is able to access a service hosted by the server or provider, an authorization token is given to the client. A token is a credential that gives access to the service. Examples of an authorization token may include an SSO token, or be fixed data, debit card or credit card information. Tokens may also allow a client to reuse the token that has already been authorized to access the web services multiple times as long as a verification server can validate the authorization of the token.

[0061] While tokens add efficiency to client-server/provider communications, as well as a layer of security, tokens can be vulnerable and become a vector of attack themselves usable by malicious actors as a vehicle to access or steal data, for example. Tokens usually comprise a unique identifying code, which can be used to authenticate the client, however, tokens may be hijacked, and then replayed and used by a malicious actor to gain access to a service, where the service believes the malicious actor is the client the token was issued to. Replay of the token is the reuse of the authenticated token to be verified by a provider or server for example. Malicious actors may also utilize a man in the middle (“MITM”) technique by hijacking a token and receive or send communications between the client and server. Finally tokens may be used to access a service in a distributed denial of service (“DDOS”) attack where the server can be flooded by access requests that aim to take the server down.

[0062] Furthermore, tokens are not bound to a specific context or usage. A platform, provider or server may allow one token to be used for various services, access different services and apps and also allow use the token for various functionalities, for example making a payment, transferring funds between an account, and requesting funds, all by using the same token. Therefore one token being captured can cause a variety of security vulnerabilities that may have been unassociated with the original use or context of the token when it was authorized. Tokens also do not carry any information about their risk profile to be conveyed to the provider. Any risk profiles or assessments of a token, a user, a client, or a device are usually separate from the token and must be stored in a centralized independent database. Finally token replay controls are stateful and do not scale well, so when a token is used, it is used in one state, but its history of other usages in different scales must be separately logged and stored for there to be a record of the token and its use making it difficult to monitor token usage.

[0063] . Tokens are typically static and remain valid for a long period allowing them to be captured and replayed. Tokens may also have imprecise scope relating to how they can be used, and can be used from various locations or clients, and have imprecise and highly variable time validity, from minutes to possibly days for example. Checking whether a token has been replayed is very difficult because a client or server must store the full history of each token to determine if it has been used in the past. Furthermore in the case of DDOS attacks, MITM attacks and other cyber-attacks, it is very difficult to detect a replayed or hijacked token during the attack, especially if there are a large number of requests being made of the server, since all tokens can look valid, and time is required to validate each one separately, this requires a large amount of processing power eventually overwhelming the server. Therefore, solutions are needed to safeguard the use of tokens in an efficient manner.

[0064] Presented in this disclosure are solutions to overcome the security vulnerabilities of tokens, safeguarding their use in accessing services to minimize malicious activity and token replays. In one aspect, the systems and methods presented secure token usage by continuously authenticating and monitoring the token owner, and/or the user device during a token validity time-frame, to take into account changes in the risk profile of the user of the token within the token validity time-frame, while limiting the number of times a token can be protected during the validity-timeframe. The technologies presented also cryptographically bind the token with user risk information and time models to produce a timecode that secures the use of token to specific timeframes and windows based on the specific context and usage of the token in those time windows.

[0065] The solutions herein include local, efficient, and stateless token validation by the provider. A provider does not require a backend to validate the token, does not have to store the token, and is able to locally validate a token it receives with a cookie or a URL request containing a cryptogram/timecode that comprises the token. The server or provider is able to generate the same cryptogram as the one it received, by using the transaction data sent to it in the request. Once it generates the cryptogram it is able to validate all risk data, and all timestamps associated with the received cryptogram based on local processing to allow use of the token.

[0066] FIG. 1 illustrates a standard token-based service access model, according to at least one aspect of the present disclosure. Typically, tokens are used as presented in model 100. A service requester 105 (also referred to herein as “requester” or “client”) may select an address of a webpage, for example, a URL, or a specific application or other service. Once it does so, a token issuance service 115 authenticates the requester 105 and provides a token to the client to allow it access to a service provider 110 or service hosted by the service provider 110 (also referred to herein as “service provider”, “provider”, or “server”). The token issuance service 115 is generally associated with the URL, server, app, or provider (collectively also referred to as “service provider”, “provider” or “server”) hosting the service that the client 105 is trying to access.

[0067] Once the requester 105 receives the token it then attempts to access the service from the service provider 110 by issuing an access request 120. The access request 120 contains the token which is validated by the service provider 110. Once the token is validated the service provider 110 delivers or allows the client 105 access to the service. There may be multiple existing services 125 that may also be accessed by the client 105 via the same token. The token may however be hijacked and used by a MITM attack or replayed 130 by a malicious actor to gain access to the service provider 110. The token may also be hijacked and used to send mass repeated requests as part of a DDOS 135 attack that attempt to overwhelm and down the server 110.

[0068] FIG. 2 illustrates a simplified diagram of a system for continuous token control, according to at least one aspect of the present disclosure. Model 200 includes a client 205 (also referred to herein as a “requester” or “service requester”), and a provider 210. In the model 200 the client 205 receives a token 220 from a token issuer or issuance service 215 that may be associated with the provider 210. Once the client 205 receives the token, the client 205, or a service or agent associated with the client 205 estimates, determines, calculates, and/or generates 225 a timecode based on an ETA model, where the ETA model determines the timeframe or validity window of the token and restricts its use to that determined timeframe via a cryptogram or timecode accessible within the calculated window(s). The client 205 may then request access by issuing a service access request 230 to the service of the provider 210 and transmit a cryptographic timecode and/or a token with the service access request 230.

[0069] FIG. 3 illustrates a flow-diagram of a method for continuous token protection and control, according to at least one aspect of the present disclosure. Referring primarily to FIG.

3 together with FIG. 2, method 300 comprises receiving 305 by a credentialing agent (also referred to herein as “agent”), a token protection request from the client 205, for example the service requester/client, FIG. 2, to generate a timecode for the token to allow the client 205 to access to a service of the provider, for example a service provider 210, FIG. 2. The credentialing agent may be a separate enclave, an application, a device, a service or app running on a user device, or be a cloud based service. Depending on the aspect, the credentialing agent may be independent from the client 205, FIG. 2, or may be associated with, or be part of the client 205, FIG. 2. Method 300 continues with receiving 310, by the credentialing agent, at least one of risk data, a timecode model, or secret parameters associated with the token. The credentialing agent may in several aspects receive or pull the timecode model or secret parameters from the provider 210, FIG. 2 or one or more services associated with the provider 210, FIG. 2. One such service is a ‘secret and clock’ distribution service, which ensures that identical secrets such as timecode model seed(s) and provider clock reference data (e.g., drift, etc.) are exchanged in advance between the provider 210, and the credentialing agent. Secret parameters can refer to any additional information needed to compute the timecode not publicly transmitted, exposed, or available to potential malicious actors. For example, a token validation service address will bind the timecode to a specific address such as that of service provider 210, FIG. 2. An application ID will bind the timecode to a specific application, which may also be provided by service provider 210, FIG.

2. An additional time window can limit the validity of the time code, to a specific time window, etc. Any combination of these parameters can be used in the computation of the time code. These secret parameters are not transmitted with the timecode, but the timecode validation service, for example a timecode validation service associated with service provider 210, FIG.

2, will use these parameters to re-compute the same timecode to validate the token. A timecode model can be defined as a timecode stream or timecode seed that can be used to generate a timecode. The timecode model can be generated using a base seed and one or multiple times. In some embodiments, the timecode model can be generated using other data such as an authorization token in addition to the base seed and the one or multiple times. When generating a timecode base stream, the time can be the timecode model validity time (e.g., start and end time of the timecode model). When generating a timecode seed, the time can be a single default time, e.g., a domain time reference that all servers agree on (e.g., a Unix25 epoch).

[0070] The credentialing agent may receive 310 the risk data, a timecode model, or secret parameters from various sources depending on the aspect. In one aspect the risk data may be received from logs or continuous monitoring of user activity, a user device, or the like. For example, a user device running the credentialing agent, or a user device running the client 205, FIG. 2 may provide the credentialing agent information on user activity or device activity. The risk data may be provided as raw risk data, or it may be provided as compiled data for the credentialing agent. In several aspects, the credentialing agent is able to pull this data from various sources including the client, users, or user devices. This risk data may contain activity information on a user of the user device running the client. For example, a user is away from screen in combination with a transaction being made, or user/device is at certain coordinates denoting a location that may be associated with the user/device, or alternatively may be a completely new location indicating a possible threat. This risk data as a whole may indicate for example that the client may be compromised, or provide a risk profile of a client, which at certain risk thresholds or scores may indicate that the client is compromised.

[0071] With continued reference to FIG. 3 together with FIG. 2, the credentialing agent can generate 315, an ETA model, based on at least one of the risk data, the timecode model, or the secret parameters, wherein the ETA model determines an ETA of the token to the provider. The ETA can be determined by opening a socket to the service provider or server 210, FIG. 2 and transmitting a communication to the socket, and by testing the latency of the transmission and time for a roundtrip- of the communication in combination with the risk assessment based on the risk data, an ETA model can be determined and generated 315. Once an ETA model is generated 315 for the token, it must then be transmitted along with the token, this could be undertaken by cryptographically binding 320, by the credentialing agent, the token, the risk data and the ETA model to generate a timecode. In several aspects, the timecode is comprised of all three. In various aspects, the timecode is a cryptogram. Finally, method 300 includes transmission 325 of the timecode to at least one of the client, the provider 210, FIG. 2, or a provider credentialing service associated with the provider 210, FIG. 2, to facilitate a validation of the timecode and the token to allow the client 205, FIG. 2 access to the service. In several aspects the client 205, FIG. 2, receives the timecode and then transmits the timecode as part of a service access request 230, FIG. 2 containing the token and the timecode to the provider 210, FIG. 2.

[0072] FIG. 4 illustrates a state of a system at a first phase of token protection and control, according to at least one aspect of the present disclosure. System 400 can include one or more user device(s) 401 connected via a public internet 402 to a provider 403 hosting remote services 404. These remote services 404 may for example be a variety of web-based applications. A client or service requester 405 is installed or is running on the user device(s) 401. The client 405 may in various aspects be an application or a browser, and may attempt to connect to the server or provider 403 to access one or more remote services 404. Once the client 405 attempts to connect 450 to the provider 403, but before the service requester/client 405 is provided access, its request is first directed or transmitted 408 to a token issuance service 407, which may be a token service provider. In various aspects, the request is transmitted to the token issuance service 407 as a token request message. In some aspects the token issuance service 407 may be part of the service provide gateway 417 (e.g., a server) (also referred to herein as “provider gateway” or “provider server”), as a remote service 404 for example, and in other aspects it may be run independently from the provider 403.

[0073] With continued reference primarily to FIG. 4, but now in combination with FIG. 3, in several aspects, the token issuance service 407 authenticates 409 the service requester/client 405 or the user 406 of the user device(s) 401 , and upon successful authentication 409, the token issuance service 407 which is generally associated with provide 403 and/or provider server 417 generates 410 a token and transmits 411 the token to the client or service requester 405, in some aspects as a token response message. The client 405 receives and registers 412 the token. There may be a service request identifier associated with the token and/or the request by the client 405, or an identifier of the service request itself. After registration, the token on its own, or along with other tokens, may be part of a transmission of a token protection request 413, for example as a function call, to a credentialing agent 414. Credentialing agent 414 may be a separate enclave, an application, a device, a service or app running on a user device 401 , or be a cloud based service. Depending on the aspect, the credentialing agent may be independent from the client 405 and/or user device(s) 401 or may be associated with, or be part of, the client 405 and/or user device(s) 401. In several aspects, the credentialing agent 414 is installed on the user device(s) 401. Transmission of the token protection request 413 may correspond with receiving 305, FIG. 3 by the credentialing agent 414 of the token protection request 413 from the client 405.

[0074] Upon receipt of the token, the credentialing agent 414 can in several aspects throttle the token, to limit the number of times it could be used or replayed, and limit the number of times it can be protected, for example by limiting the number of valid timecodes generated, or limiting the frequency of timecode generation per second in association with the service request. This is helpful because a malicious actor may try to replay a token based on the allowed time window and slow down the network. If the malicious actor has more timecode samples/tokens to work on, they can optimize an attack. Therefore, limiting the number of timecodes generated per time unit provides an additional layer of protection.

[0075] In various aspects, the credentialing agent 414 initiates an end-to-end encryption 415 between itself and a credentialing service 416. The credentialing service 416 may be part of the provider 403, for example as a remote service 404, or be associated, or in communication with the provider 403. The provider 403 can include or be associated with any of the remote services 404 including the token issuance service 407 or the web server or the service provider gateway 417. The provider gateway 417 may also possess service keys 424 to allow access to one or more services of the provider 403. An example of the provider gateway 417 is a payment gateway. The credentialing service 416 may in some aspects be a host communication and terminal emulation package, such as an identity provider (for example an identity provide file (“I DP fil”)e or extension). The initiating of end- to-end encryption 415 between the credentialing agent 414 and the credentialing service 416 can serve to authenticate the credentialing agent 414 that is on the client 405 or the user device 401 side to the credentialing service 416.

[0076] Once the credentialing service 416 associates or recognizes the credentialing agent 414 as being part of the user device 401 , or associated with the client or service requester 405, the credentialing agent 414 can directly or indirectly via the client 405, request 418 token protection data from the credentialing service 416 to access service(s) of the provider 403. The credentialing service 416 may transmit/deliver 419 token protection data to credentialing agent 414. In several aspects, the credentialing service 416 may allow transmission of token protection data after verifying the token in possession of the credentialing agent 414 and/or verifying other identifiers associated to the credentialing agent 414, including an identifier of the service requested by the client 405 or an identifier of the request itself, for example a service request identifier. In several aspects, the credentialing service 416 does not possess all token protection data. Some of these components of the token protection data including for example the remote clock may have to be obtained or requested 420 from the service provider gateway 417, or web server, of the provider 403, which can provide the credentialing service 416 with the clock parameters 421 for example, upon request 420. The credentialing service 416 may also possess master keys 422. Master keys are typically Timecode seeds that are provided to the credentialing agent 414 to calculate an ETA model. Meanwhile service keys are credential service keys, in various instances service keys and master keys are interchangeable.

[0077] With continued reference primarily to FIG. 4 together with FIG. 3, token protection data is data that the credentialing agent 414 can use to add protections to a token, these may include a remote clock, timecode model, signing policy, token signing certificate(s), and a token validation service address, as well as other secret parameters. The remote clock is the provider clock, which provides and determines which parameters (such as drift) can be delivered to the credentialing agent in advance. The timecode model is a set of parameters that describe how the time code is generated and signed. A timecode model (e.g., timecode stream or timecode seed) can be used to generate a timecode by being used as an input to generate an ETA model. It is one variable that is used to calculate and generate the ETA model.

[0078] For example, the timecode model can be generated using a base seed and one or multiple times. In some embodiments, the timecode model can be generated using other data such as the authorization token in addition to the base seed and the one or multiple times. When generating a timecode base stream, the time can be the timecode model validity time (e.g., start and end time of the timecode model). When generating a timecode seed, the time can be a single default time, i.e. a domain time reference that all servers agree on (e.g., a Unix 25 epoch).

[0079] The signing policy and token signing certificate is used as an extension of the timecode model when the timecode cryptogram is based on signature with private keys and certificates (instead of Hash-based message authentication code (or “HMAC”). The Token Validation service address is a secret parameter. In addition to the timecode, the credentialing agent 414 may receive risk data, for example user risk data or user device data from the user device 101 or the user 406. The credentialing agent 414 may continuously monitor the user 406, the user 406 activity, or the user device(s) 401 to continuously update the risk data. The receipt of token protection data and risk data may correspond to receiving 310, FIG. 3 by the credentialing agent 414 of at least one of risk data, a timecode model, or secret parameters associated with the token. In several aspects, the client 405, the credentialing agent, or other application on the user device registers or saves the token protection data for further use for other future tokens. Token protection data can for example be stored in a storage or token vault 423 of the credentialing agent 414 for further use. [0080] FIG. 5 illustrates a state of a system at a second phase of token protection and control, according to at least one aspect of the present disclosure. With reference primarily to FIG. 5 together with FIG. 4, in several aspects, after the service requester/client 405 selects or attempts to connect 498 to a URL or other service address, it receives a token 499, from a token issuance service 407, FIG. 4. The client 405 then makes a token protection request 413, FIG. 4 for example, a request to generate a timecode to be attached to the token to the credentialing agent 414. The credentialing agent may in addition, request 418, FIG. 4 token protection data, may receive, pull, or request risk data or risk data 425, from the user 406, the user device(s) 401, or user activity data associated with either the user 406 or the user device(s) 401.

[0081] With continued reference primarily to FIG. 5 together with FIG. 4, in several aspects, after the credentialing agent 414 receives a transmission or delivery 419, FIG. 4, of token protection data, from the credentialing service 416 that is associated with the service provider 417 (and token/time code validator), wherein the token protection data delivered 419 includes the time code model (that comprises a seed) and the remote clock parameters. The credentialing agent 414 also receives continuous risk data or risk data 425 from the user 406, the client 405, or user device(s) 401 which continuously monitors the token usage context, for example, device(s), user(s), etc. And also as described above, it may proceed to use this data to provide security protections to the token. In one aspect, the credentialing agent 414 uses one or more of the risk data 425, e.g., risk level, and the time code model, as well as other secret parameter(s) received 418 as part of the token protection data to generate 426 an ETA model. The generating 426 may comprise determining or calculating the ETA model based on the risk level (which can be a continuous risk assessment), a calculated latency (described below) and the time code model, as well as other secret parameter(s). The ETA model determines an estimated time of arrival of the token to the provider and may limit the usability of the token to the time within the estimated time of arrival. A latency check is made from the credentialing agent 414 immediately preceding the request to send the token, for example, when the user starts the transaction, this opens a socket and the communication comes back to the credentialing agent 414. For example if the round-trip is 6 seconds, ETA model is determined to have an ETA of 3 seconds (time taken for a one-way trip to the open socket). By combining the ETA with a risk-based timewindow, the time window length of a timecode is not the ETA time but a newly calculated time window that takes into account the continuous risk data. In several aspects the latency calculated is generally close to the range of +/- 100 ms. Therefore the token may only be used during that calculated time window in the calculated range of +/- 100 ms., to access the service of provider 403. [0082] In several aspects the ETA model defines several different time windows, i.e., allowable time windows for a token to be utilized or activated to access the service 430. The time code model transmitted or delivered 419, FIG. 4 to the credentialing agent 414 can be a time code model of the requested service 430 and/or of the server/provider 403, and allows the credentialing agent 414 to calculate validity time windows or segments for the token to be used to access service 430. It does so by generating a time code that adheres to the service 430’s and/or the server 403’s time code model, and in many instances based on a service clock of the time code model. For example if the allowable window calculated by the ETA model is five seconds from creation of a token until its arrival to the provider 403, then usability timeframes may be defined to further limit when during the estimated ETA, either with or a life-time of a token can the token be used to access services, for example between seconds 2-3 and seconds 4-5.

[0083] In several aspects, the credentialing agent 414 must connect 438 to the provider gateway 417 to determine or calculate the ETA model. For example the credentialing agent 414 builds a multimodal Token ETA model in real-time which includes a base ETA and/or relative validity windows within the base ETA. In one example the ETA model can be a list of time segments/windows where the token is valid or usable to access services: [t+95ms, t+105ms], [t+205ms, t+243] where “t” is the time when the request is sent. In several aspects, the ETA model can comprise a complex non-Gaussian multimodal probability distribution over time. A time window or time segments is an approximation for a Gaussian probability distribution. In many aspects the ETA model is a collection of one or more allowed time windows.

[0084] In several aspects, upon generating 426 an ETA model, the credentialing agent 414 is able to compute 427 a time code that is generated based on the time code model, the ETA model and the risk, and the token value itself. A time code is the primary means or protection of the token to block replays, or other malicious cyber activity such as MITM, DDOS, or relay attacks. The time code is used to protect any service request with tokens and/or credentials, (e.g., PAN, cookie, SSO token, user id/password, user OTP). The time code is generated by combining and encrypting the ETA model generated 426, the risk data 425 and the received token 499. The time code can be a cryptogram that is a result of cryptographically binding the ETA model generated 426, the risk data 425 and the token. Once a time code is generated or computed 427 it may be added 429 to an HTTP header of a URL request, such as an HTTPs request, with the header containing the time code that includes the token, the ETA model, and the risk data. The URL request is transmitted to the provider gateway 417, for example through a security node, or security layer 432 such as a TLS layer.

[0085] In several aspects once the security layer 432 receives the URL service request 431, and the included time code. It first parses the HTTP header to extract the time code. The security layer 432 then validates or verifies 433 the time code before accessing the token within the time code. If the security layer 432 does not encounter a security event when verifying 433 the time code, the verification 433 can be undertaken by the service 417 or the provider 403. Generally verification 433 will comprise the server of provider 403 or gateway 417 will generate the same (second) time code with locally available information and current local clock, with the precision of the ETA time window that is communicated as part of the time code (or multiple time codes during this ETA time window). The (first) time code received must match one of the (second) time codes generated with the validation server. Generally the validation server will generate the same (second) time code with locally available information and current local clock, with the precision of the ETA time window that is communicated as part of the timecode (or multiple timecodes during this ETA time window). The (first) time code received must match one of the (second) timecodes generated with the validation server. For example by determining that the token is within a usable time segment or authorized time window, according to the time code model of the service 430 it can eliminate 434 the time code from service request 431, and extract the token, and validate 435 the token’s validity, allowing access to the service 430. Access is allowed to the service 430 by providing service keys 436, and allowing the request and token to be processed 437 by the service 430. In several aspects the verification of the time code is undertaken by the security layer 432 by using the information in service request 431 attempts to recreate the cryptogram, for example by using hash based message authentication code (HMAC). Once the cryptogram is generated by the security layer 432 it validates the time code.

[0086] FIG. 6 illustrates a framework to measuring or determining an ETA model for a token within a system of token protection and control, according to at least one aspect of the present disclosure. With primary reference to FIG. 6 and continued reference to FIG. 4-5, framework 600 may begin when a token is selected by the client 405 which makes a request 413 for it to be protected by the credentialing agent 414, as described above in FIG. 4-5 for example. The credentialing agent 414 first measures 428 a token’s estimated time of arrival. It measures 428 this by launching multiple parallel threads with individual connection attempts to the service provider gateway 417 or the provider 403 in order to measure latency as described above. These connection attempts may be via a TCP protocol connection for example. The credentialing agent 414 may measure a number of parameters including the time it takes to open and close a TCP connection via a connection request, the time information is relayed back and forth between the credentialing agent 414 and the provider gateway 417, as well as the latencies between the credentialing agent 414 and the provider gateway 417. In several aspects, this information is used to build or generate an ETA model as already discussed in this disclosure, for example in FIG. 3-5. The ETA model defines ETA windows or segments assuming multimodal or nonlinear behavior, and based on a clock it computes a time code.

[0087] FIG. 7 illustrates a cryptographic binding of various components to generate a timecode, according to at least one aspect of the present disclosure. Referencing FIG. 7 together with FIG. 4-5, a token 701 is provided to a credentialing agent or continuous authentication agent, for example, credentialing agent 414, FIG. 4. The agent can generate a time code 705, with the token 701 , risk level/risk information 702, and an ETA model/elapsed time since token issuance 703 by cryptographically signing this combination via keys and/or certificates to generate the time code 705 by the credentialing agent, for example credentialing agent 414, FIG. 4-6. In several aspects the risk information is retrieved from user devices(s), users, user activity, the client, or from other sources. The risk data or information is self-contained and can be continuously monitored even after a token and time code are verified by a server gateway or a service, for example, the provider gateway 417, and the service 430, FIG. 5, respectively.

[0088] In several aspects, the risk information or data is continuously monitored throughout the lifetime of the token by the credentialing agent 414, requester 405 and/or user device(s) 401 FIG. 4-6, or throughout the token validity time-frame as determined by the ETA model. Therefore the risk information includes any variation on authentication risk during the token’s lifetime. Continuous risk monitoring could be undertaken by behavioral analysis of a user for example via video, smart watch, using geolocation, microphone, biometric data and the like. This information may indicate whether user presence has been continuous during the token life time, or whether to allow re-authentication or extension of the validity time window to resume or renew access to a service. Furthermore, the risk score based on this continuous gathering of data or risk information is enforced and causes changes to a time code, as new risk data is collected and new or extended time codes are generated, then the new risk data may be included into the new or extended time codes.

[0089] With reference to FIG. 7 in addition to FIG. 1 , a token lifetime or validation time may also be extended, in which case the time code 705, e.g., original time code, may be cryptographically signed along with new or updated risk information 706 and the token 701 , e.g., original token 701 , via token signing key and/or certificate 704, to produce a new data packet 707 or time code 707 that can be sent to a provider gateway to access its services which includes the original timecode information 705. Token 701 is a standard token as currently sent by traditional technologies such as system 100, FIG. 1 to a token validation server. The credentialing agent 714, Fig. 5-6 calculates the timecode 705 by using the token 701, the continuous risk information 702, and the ETA model 703 (computed generally via a latency check) using these to generate time code 705. The token 701 is combined with the timecode 705 and continuous risk information 706, and token signing certificate(s) 704 and sent to the validation server 417, FIG. 4 as a cryptogram.

[0090] FIG. 8 is a block diagram of a computer apparatus 3000 with data processing subsystems or components, which a set of instructions to perform any one or more of the methodologies discussed herein may be executed, according to at least one aspect of the present disclosure. The subsystems shown in FIG. 8 are interconnected via a system bus 3010. Additional subsystems such as a printer 3018, keyboard 3026, fixed disk 3028 (or other memory comprising computer readable media), monitor 3022, which is coupled to a display adapter 3020, and others are shown. Peripherals and input/output (I/O) devices, which couple to an I/O controller 3012 (which can be a processor or other suitable controller), can be connected to the computer system by any number of means known in the art, such as a serial port 3024. For example, the serial port 3024 or external interface 3030 can be used to connect the computer apparatus to a wide area network such as the Internet, a mouse input device, or a scanner. The interconnection via system bus allows the central processor 3016 to communicate with each subsystem and to control the execution of instructions from system memory 3014 or the fixed disk 3028, as well as the exchange of information between subsystems. The system memory 3014 and/or the fixed disk 3028 may embody a computer readable medium.

[0091] FIG. 9 is a diagrammatic representation of an example system 4000 that includes a host machine 4002 within which a set of instructions to perform any one or more of the methodologies discussed herein may be executed, according to at least one aspect of the present disclosure. In various aspects, the host machine 4002 operates as a standalone device or may be connected (e.g., networked) to other machines. In a networked deployment, the host machine 4002 may operate in the capacity of a server or a client machine in a server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The host machine 3002 may be a computer or computing device, a personal computer (PC), a tablet PC, a set-top box (STB), a personal digital assistant (PDA), a cellular telephone, a portable music player (e.g., a portable hard drive audio device such as an Moving Picture Experts Group Audio Layer 3 ( P3) player), a web appliance, a network router, switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.

[0092] The example system 4000 includes the host machine 4002, running a host operating system (OS) 4004 on a processor or multiple processor(s)/processor core(s) 4006 (e.g., a central processing unit (CPU), a graphics processing unit (GPU), or both), and various memory nodes 4008. The host OS 4004 may include a hypervisor 4010 which is able to control the functions and/or communicate with a virtual machine (“VM”) 4012 running on machine readable media. The VM 4012 also may include a virtual CPU or vCPU 4014. The memory nodes 4008 may be linked or pinned to virtual memory nodes or vNodes 4016. When the memory node 4008 is linked or pinned to a corresponding vNode 4016, then data may be mapped directly from the memory nodes 4008 to their corresponding vNodes 4016.

[0093] All the various components shown in host machine 4002 may be connected with and to each other, or communicate to each other via a bus (not shown) or via other coupling or communication channels or mechanisms. The host machine 4002 may further include a video display, audio device or other peripherals 4018 (e.g., a liquid crystal display (LCD), alpha-numeric input device(s) including, e.g., a keyboard, a cursor control device, e.g., a mouse, a voice recognition or biometric verification unit, an external drive, a signal generation device, e.g., a speaker,) a persistent storage device 4020 (also referred to as disk drive unit), and a network interface device 4022. The host machine 4002 may further include a data encryption module (not shown) to encrypt data. The components provided in the host machine 4002 are those typically found in computer systems that may be suitable for use with aspects of the present disclosure and are intended to represent a broad category of such computer components that are known in the art. Thus, the system 4000 can be a server, minicomputer, mainframe computer, or any other computer system. The computer may also include different bus configurations, networked platforms, multiprocessor platforms, and the like. Various operating systems may be used including UNIX, LINUX, WINDOWS, QNX ANDROID, IOS, CHROME, TIZEN, and other suitable operating systems.

[0094] The disk drive unit 4024 also may be a Solid-state Drive (SSD), a hard disk drive (HDD) or other includes a computer or machine-readable medium on which is stored one or more sets of instructions and data structures (e.g., data/instructions 4026) embodying or utilizing any one or more of the methodologies or functions described herein. The data/instructions 4026 also may reside, completely or at least partially, within the main memory node 4008 and/or within the processor(s) 4006 during execution thereof by the host machine 4002. The data/instructions 4026 may further be transmitted or received over a network 4028 via the network interface device 4022 utilizing any one of several well-known transfer protocols (e g., Hyper Text Transfer Protocol (HTTP)).

[0095] The processor(s) 4006 and memory nodes 4008 also may comprise machine- readable media. The term "computer-readable medium" or “machine-readable medium” should be taken to include a single medium or multiple medium (e.g., a centralized or distributed database and/or associated caches and servers) that store the one or more sets of instructions. The term "computer-readable medium" shall also be taken to include any medium that is capable of storing, encoding, or carrying a set of instructions for execution by the host machine 4002 and that causes the host machine 4002 to perform any one or more of the methodologies of the present application, or that is capable of storing, encoding, or carrying data structures utilized by or associated with such a set of instructions. The term “computer-readable medium” shall accordingly be taken to include, but not be limited to, solid-state memories, optical and magnetic media, and carrier wave signals. Such media may also include, without limitation, hard disks, floppy disks, flash memory cards, digital video disks, random access memory (RAM), read only memory (ROM), and the like. The example aspects described herein may be implemented in an operating environment comprising software installed on a computer, in hardware, or in a combination of software and hardware.

[0096] One skilled in the art will recognize that Internet service may be configured to provide Internet access to one or more computing devices that are coupled to the Internet service, and that the computing devices may include one or more processors, buses, memory devices, display devices, input/output devices, and the like. Furthermore, those skilled in the art may appreciate that the Internet service may be coupled to one or more databases, repositories, servers, and the like, which may be utilized to implement any of the various aspects of the disclosure as described herein.

[0097] The computer program instructions also may be loaded onto a computer, a server, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.

[0098] Suitable networks may include or interface with any one or more of, for instance, a local intranet, a PAN (Personal Area Network), a LAN (Local Area Network), a WAN (Wide Area Network), a MAN (Metropolitan Area Network), a virtual private network (VPN), a storage area network (SAN), a frame relay connection, an Advanced Intelligent Network (AIN) connection, a synchronous optical network (SONET) connection, a digital T1, T3, E1 or E3 line, Digital Data Service (DDS) connection, DSL (Digital Subscriber Line) connection, an Ethernet connection, an ISDN (Integrated Services Digital Network) line, a dial-up port such as a V.90, V.34 or V.34bis analog modem connection, a cable modem, an ATM (Asynchronous Transfer Mode) connection, or an FDDI (Fiber Distributed Data Interface) or CDDI (Copper Distributed Data Interface) connection. Furthermore, communications may also include links to any of a variety of wireless networks, including WAP (Wireless Application Protocol), GPRS (General Packet Radio Service), GSM (Global System for Mobile Communication), CDMA (Code Division Multiple Access) or TDMA (Time Division Multiple Access), cellular phone networks, GPS (Global Positioning System), CDPD (cellular digital packet data), RIM (Research in Motion, Limited) duplex paging network, Bluetooth radio, or an IEEE 802.11 -based radio frequency network. The network comprising the server 4030 can further include or interface with any one or more of an RS-232 serial connection, an I EEE- 1394 (Firewire) connection, a Fiber Channel connection, an IrDA (infrared) port, a SCSI (Small Computer Systems Interface) connection, a USB (Universal Serial Bus) connection or other wired or wireless, digital or analog interface or connection, mesh or Digi® networking.

[0099] In general, a cloud-based computing environment is a resource that typically combines the computational power of a large grouping of processors (such as within web servers) and/or that combines the storage capacity of a large grouping of computer memories or storage devices. Systems that provide cloud-based resources may be utilized exclusively by their owners or such systems may be accessible to outside users who deploy applications within the computing infrastructure to obtain the benefit of large computational or storage resources.

[0100] The cloud is formed, for example, by a network of web servers that comprise a plurality of computing devices, such as the host machine 4002, with each server 4030 (or at least a plurality thereof) providing processor and/or storage resources. These servers manage workloads provided by multiple users (e.g., cloud resource customers or other users). Typically, each user places workload demands upon the cloud that vary in real-time, sometimes dramatically. The nature and extent of these variations typically depends on the type of business associated with the user.

[0101] It is noteworthy that any hardware platform suitable for performing the processing described herein is suitable for use with the technology. The terms “computer-readable storage medium” and “computer-readable storage media” as used herein refer to any medium or media that participate in providing instructions to a CPU for execution. Such media can take many forms, including, but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media include, for example, optical or magnetic disks, such as a fixed disk. Volatile media include dynamic memory, such as system RAM. Transmission media include coaxial cables, copper wire and fiber optics, among others, including the wires that comprise one aspect of a bus. Transmission media can also take the form of acoustic or light waves, such as those generated during radio frequency (RF) and infrared (IR) data communications. Common forms of computer-readable media include, for example, a flexible disk, a hard disk, magnetic tape, any other magnetic medium, a CD-ROM disk, digital video disk (DVD), any other optical medium, any other physical medium with patterns of marks or holes, a RAM, a PROM, an EPROM, an EEPROM, a FLASH EPROM, any other memory chip or data exchange adapter, a carrier wave, or any other medium from which a computer can read.

[0102] Various forms of computer-readable media may be involved in carrying one or more sequences of one or more instructions to a CPU for execution. A bus carries the data to system RAM, from which a CPU retrieves and executes the instructions. The instructions received by system RAM can optionally be stored on a fixed disk either before or after execution by a CPU.

[0103] Computer program code for carrying out operations for aspects of the present technology may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++, or the like and conventional procedural programming languages, such as the "C" programming language, Go, Python, or other programming languages, including assembly languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).

[0104] Examples of the method according to various aspects of the present disclosure are provided below in the following numbered clauses. An aspect of the method may include any one or more than one, and any combination of, the numbered clauses described below.

[0105] Clause 1. A computer implemented method for continuous token monitoring and control, comprising receiving, by a credentialing agent, a token protection request from a client, to generate a time code for the token to allow client access to a service of a provider; receiving, by the credentialing agent, at least one of risk data, a time code model, or secret parameters associated with the token; generating, by the credentialing agent, an ETA model, based on at least one of the risk data, the time code model, or the secret parameters, wherein the ETA model determines an estimated time of arrival (ETA) of the token to the provider; cryptographically binding, by the credentialing agent, the token, the risk data and the ETA model to generate a time code; and transmitting, the time code to at least one of the client, the provider, or a provider credentialing service, to facilitate a validation of the time code and the token to allow the client access to the service.

[0106] Clause 2. The computer implemented method of Clause 1 , wherein the ETA model is a token validity time window.

[0107] Clause 3. The computer implemented method of any of Clauses 1-2, further comprising monitoring, by the credentialing agent, the risk data, during the token validity time window, wherein the monitoring can take into account new factors or events that adjust the risk data.

[0108] Clause 4. The computer implemented method of any of Clause 1-3, further comprising determining, by the credentialing agent, based on the monitoring, that the risk data meets or exceeds a risk threshold; and invalidating, by the credentialing agent, at least one of the token, the risk data, the ETA model, or the time code.

[0109] Clause 5. The computer implemented method of any of Clauses 1-4, further comprising determining, by the credentialing agent, based on the monitoring, that a risk score does not reach a risk threshold.

[0110] Clause 6. The computer implemented method of any of Clauses 1-5, further comprising extending the token validity time window by the credentialing agent.

[0111] Clause 7. The computer implemented method of any of Clauses 1-6, wherein the ETA model is calculated using a service clock of the time code model.

[0112] Clause 8. The computer implemented method of any of Clauses 1 -7, wherein the time code is verified by the service, the provider, a provider service gateway web server, a Transport Layer Security, or a provider credentialing service, to access the token.

[0113] Clause 9. The computer implemented method of any of Clauses 1 -8, wherein the credentialing agent is associated to the client. [0114] Clause 10. The computer implemented method of any of Clauses 1-9, wherein the risk data meets or exceeds a threshold, preventing the generating of a time code.

[0115] Clause 11. A system for continuous token monitoring and control, the system comprising: a provider that provides a web service; a credentialing service, associated to the provider, to manage service requests to the web service; a client, running on a user device, that requests access to the web service; and a credentialing agent, associated to the client, the credentialing agent configured to: receive, a token protection request from the client, to generate a time code for the token to allow client access to a service of a provider; receive, at least one of risk data, a time code model, or secret parameters associated with the token; generate, an ETA model, based on at least one of the risk data, the time code model, or the secret parameters, wherein the ETA model determines an estimated time of arrival (ETA) of the token to the provider; cryptographically bind, the token, the risk data and the ETA model to generate a time code; and transmit, the time code to at least one of the client, the provider, the web service, or a provider credentialing service.

[0116] Clause 12. The system of Clause 11, wherein the credentialing agent is further configured to: receive, token protection data that originated from the credentialing service, based on the token and an identifier of the web service.

[0117] Clause 13. The system of any of Clauses 11-12, wherein at least one of the credentialing agent or the client are further configured to: register the token protection data for further use.

[0118] Clause 14. The system of any of Clauses 11-13, wherein the token protection data comprises at least one of a remote clock, a time code model, a signing policy, a token signing certificate, a token validation service address, or secret parameters.

[0119] Clause 15. The system of any of Clauses 11-14 for continuous token monitoring and control, the system further comprising: a token issuance service, configured to: receive a service access request from the client to access the web service; authenticate the client; generate the token upon successful authentication; and transmit the token to the client.

[0120] Clause 16. The system of any of Clauses 11-15, wherein the client is configured to: request access to the web service from at least one of a token issuance service, the provider, or the web service; receive the token from at least one of a token issuance service, the provider, or the web service; register the token; and request token protection from the credentialing agent. [0121] Clause 17. The system of any of Clauses 11-16, wherein the credentialing agent is at least one of an isolated enclave, a container, a cloud based app, or a computing device app.

[0122] Clause 18. The system of any of Clauses 11-17, wherein the provider comprises a gateway web server.

[0123] Clause 19. The system of any of Clauses 11-18, wherein the client is configured to: add the time code to an HTTP header; and transmit a request comprising the HTTP header and the time code to at least one of the credentialing service, the provider, or the web service.

[0124] Clause 20. A computer implemented method for authenticating a received token, comprising receiving, by at least one of a provider of a service, the service, a credentialing service, a provider gateway, a provider web server, or a security stack, a request comprising a time code comprising a token and an HTTP header from a client; extracting, by the security stack, the time code from the request; validating, the time code, by the security stack; and based on the validating, processing, by at least one of the provider gateway, the provider web server, or the security stack, the token from the time code; and processing, by the service, the request to allow a client access to the service.

[0125] The foregoing detailed description has set forth various forms of the systems and/or processes via the use of block diagrams, flowcharts, and/or examples. Insofar as such block diagrams, flowcharts, and/or examples contain one or more functions and/or operations, it will be understood by those within the art that each function and/or operation within such block diagrams, flowcharts, and/or examples can be implemented, individually and/or collectively, by a wide range of hardware, software, firmware, or virtually any combination thereof. Those skilled in the art will recognize that some aspects of the forms disclosed herein, in whole or in part, can be equivalently implemented in integrated circuits, as one or more computer programs running on one or more computers (e.g., as one or more programs running on one or more computer systems), as one or more programs running on one or more processors (e.g., as one or more programs running on one or more microprocessors), as firmware, or as virtually any combination thereof, and that designing the circuitry and/or writing the code for the software and or firmware would be well within the skill of one of skill in the art in light of this disclosure. In addition, those skilled in the art will appreciate that the mechanisms of the subject matter described herein are capable of being distributed as one or more program products in a variety of forms, and that an illustrative form of the subject matter described herein applies regardless of the particular type of signal bearing medium used to actually carry out the distribution.

[0126] Instructions used to program logic to perform various disclosed aspects can be stored within a memory in the system, such as dynamic random access memory (DRAM), cache, flash memory, or other storage. Furthermore, the instructions can be distributed via a network or by way of other computer readable media. Thus a machine-readable medium may include any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computer), but is not limited to, floppy diskettes, optical disks, compact disc, read-only memory (CD-ROMs), and magneto-optical disks, read-only memory (ROMs), random access memory (RAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic or optical cards, flash memory, or a tangible, machine-readable storage used in the transmission of information over the Internet via electrical, optical, acoustical or other forms of propagated signals (e.g., carrier waves, infrared signals, digital signals, etc.). Accordingly, the non- transitory computer-readable medium includes any type of tangible machine-readable medium suitable for storing or transmitting electronic instructions or information in a form readable by a machine (e.g., a computer).

[0127] Any of the software components or functions described in this application, may be implemented as software code to be executed by a processor using any suitable computer language such as, for example, Python, Java, C++ or Perl using, for example, conventional or object-oriented techniques. The software code may be stored as a series of instructions, or commands on a computer readable medium, such as RAM, ROM, a magnetic medium such as a hard-drive or a floppy disk, or an optical medium such as a CD- ROM. Any such computer readable medium may reside on or within a single computational apparatus, and may be present on or within different computational apparatuses within a system or network.

[0128] As used in any aspect herein, the term “logic” may refer to an app, software, firmware and/or circuitry configured to perform any of the aforementioned operations. Software may be embodied as a software package, code, instructions, instruction sets and/or data recorded on non-transitory computer readable storage medium. Firmware may be embodied as code, instructions or instruction sets and/or data that are hard-coded (e.g., nonvolatile) in memory devices.

[0129] As used in any aspect herein, the terms “component,” “system,” “module” and the like can refer to a computer-related entity, either hardware, a combination of hardware and software, software, or software in execution. [0130] As used in any aspect herein, an “algorithm” refers to a self-consistent sequence of steps leading to a desired result, where a “step” refers to a manipulation of physical quantities and/or logic states which may, though need not necessarily, take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It is common usage to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like. These and similar terms may be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities and/or states.

[0131] A network may include a packet switched network. The communication devices may be capable of communicating with each other using a selected packet switched network communications protocol. One example communications protocol may include an Ethernet communications protocol which may be capable of permitting communication using a Transmission Control Protocol/lnternet Protocol (TCP/IP). The Ethernet protocol may comply or be compatible with the Ethernet standard published by the Institute of Electrical and Electronics Engineers (IEEE) titled “IEEE 802.3 Standard”, published in December, 2008 and/or later versions of this standard. Alternatively or additionally, the communication devices may be capable of communicating with each other using an X.25 communications protocol. The X.25 communications protocol may comply or be compatible with a standard promulgated by the International Telecommunication Union-Telecommunication Standardization Sector (ITU-T). Alternatively or additionally, the communication devices may be capable of communicating with each other using a frame relay communications protocol. The frame relay communications protocol may comply or be compatible with a standard promulgated by Consultative Committee for International Telegraph and Telephone (CCITT) and/or the American National Standards Institute (ANSI). Alternatively or additionally, the transceivers may be capable of communicating with each other using an Asynchronous Transfer Mode (ATM) communications protocol. The ATM communications protocol may comply or be compatible with an ATM standard published by the ATM Forum titled “ATM- MPLS Network Interworking 2.0” published August 2001 , and/or later versions of this standard. Of course, different and/or after-developed connection-oriented network communication protocols are equally contemplated herein.

[0132] Unless specifically stated otherwise as apparent from the foregoing disclosure, it is appreciated that, throughout the present disclosure, discussions using terms such as “processing,” “computing,” “calculating,” “determining,” “displaying,” or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.

[0133] One or more components may be referred to herein as “configured to,” “configurable to,” “operable/operative to,” “adapted/adaptable,” “able to,” “conformable/conformed to,” etc. Those skilled in the art will recognize that “configured to” can generally encompass active-state components and/or inactive-state components and/or standby-state components, unless context requires otherwise.

[0134] Those skilled in the art will recognize that, in general, terms used herein, and especially in the appended claims (e.g., bodies of the appended claims) are generally intended as “open” terms (e.g., the term “including” should be interpreted as “including but not limited to,” the term “having” should be interpreted as “having at least,” the term “includes” should be interpreted as “includes but is not limited to,” etc.). It will be further understood by those within the art that if a specific number of an introduced claim recitation is intended, such an intent will be explicitly recited in the claim, and in the absence of such recitation no such intent is present. For example, as an aid to understanding, the following appended claims may contain usage of the introductory phrases “at least one” and “one or more” to introduce claim recitations. However, the use of such phrases should not be construed to imply that the introduction of a claim recitation by the indefinite articles “a” or “an” limits any particular claim containing such introduced claim recitation to claims containing only one such recitation, even when the same claim includes the introductory phrases “one or more” or “at least one” and indefinite articles such as “a” or “an” (e.g., “a” and/or “an” should typically be interpreted to mean “at least one” or “one or more”); the same holds true for the use of definite articles used to introduce claim recitations.

[0135] In addition, even if a specific number of an introduced claim recitation is explicitly recited, those skilled in the art will recognize that such recitation should typically be interpreted to mean at least the recited number (e.g., the bare recitation of “two recitations,” without other modifiers, typically means at least two recitations, or two or more recitations). Furthermore, in those instances where a convention analogous to “at least one of A, B, and C, etc.” is used, in general such a construction is intended in the sense one having skill in the art would understand the convention (e.g., “a system having at least one of A, B, and C” would include but not be limited to systems that have A alone, B alone, C alone, A and B together, A and C together, B and C together, and/or A, B, and C together, etc.). In those instances where a convention analogous to “at least one of A, B, or C, etc.” is used, in general such a construction is intended in the sense one having skill in the art would understand the convention (e.g., “a system having at least one of A, B, or C” would include but not be limited to systems that have A alone, B alone, C alone, A and B together, A and C together, B and C together, and/or A, B, and C together, etc.). It will be further understood by those within the art that typically a disjunctive word and/or phrase presenting two or more alternative terms, whether in the description, claims, or drawings, should be understood to contemplate the possibilities of including one of the terms, either of the terms, or both terms unless context dictates otherwise. For example, the phrase “A or B” will be typically understood to include the possibilities of “A” or “B” or “A and B.”

[0136] With respect to the appended claims, those skilled in the art will appreciate that recited operations therein may generally be performed in any order. Also, although various operational flow diagrams are presented in a sequence(s), it should be understood that the various operations may be performed in other orders than those which are illustrated, or may be performed concurrently. Examples of such alternate orderings may include overlapping, interleaved, interrupted, reordered, incremental, preparatory, supplemental, simultaneous, reverse, or other variant orderings, unless context dictates otherwise. Furthermore, terms like “responsive to,” “related to,” or other past-tense adjectives are generally not intended to exclude such variants, unless context dictates otherwise.

[0137] It is worthy to note that any reference to “one aspect,” “an aspect,” “an exemplification,” “one exemplification,” and the like means that a particular feature, structure, or characteristic described in connection with the aspect is included in at least one aspect. Thus, appearances of the phrases “in one aspect,” “in an aspect,” “in an exemplification,” and “in one exemplification” in various places throughout the specification are not necessarily all referring to the same aspect. Furthermore, the particular features, structures or characteristics may be combined in any suitable manner in one or more aspects.

[0138] As used herein, the term “comprising” is not intended to be limiting, but may be a transitional term synonymous with “including,” “containing,” or “characterized by.” The term “comprising” may thereby be inclusive or open-ended and does not exclude additional, unrecited elements or method steps when used in a claim. For instance, in describing a method, “comprising” indicates that the claim is open-ended and allows for additional steps. In describing a device, “comprising” may mean that a named element(s) may be essential for an embodiment or aspect, but other elements may be added and still form a construct within the scope of a claim. In contrast, the transitional phrase “consisting of’ excludes any element, step, or ingredient not specified in a claim. This is consistent with the use of the term throughout the specification. [0139] As used herein, the singular form of “a”, “an”, and “the” include the plural references unless the context clearly dictates otherwise.

[0140] Any patent application, patent, non-patent publication, or other disclosure material referred to in this specification and/or listed in any Application Data Sheet is incorporated by reference herein, to the extent that the incorporated materials is not inconsistent herewith. As such, and to the extent necessary, the disclosure as explicitly set forth herein supersedes any conflicting material incorporated herein by reference. Any material, or portion thereof, that is said to be incorporated by reference herein, but which conflicts with existing definitions, statements, or other disclosure material set forth herein will only be incorporated to the extent that no conflict arises between that incorporated material and the existing disclosure material. None is admitted to be prior art.

[0141] In summary, numerous benefits have been described which result from employing the concepts described herein. The foregoing description of the one or more forms has been presented for purposes of illustration and description. It is not intended to be exhaustive or limiting to the precise form disclosed. Modifications or variations are possible in light of the above teachings. The one or more forms were chosen and described in order to illustrate principles and practical application to thereby enable one of ordinary skill in the art to utilize the various forms and with various modifications as are suited to the particular use contemplated. It is intended that the claims submitted herewith define the overall scope.

Claims

CLAIMS What is claimed is:

1 . A computer implemented method for continuous token monitoring and control, comprising: receiving, by a credentialing agent, a token protection request from a client, to generate a time code for a token to allow client access to a service of a provider; receiving, by the credentialing agent, at least one of risk data, a time code model, or secret parameters associated with the token; generating, by the credentialing agent, an ETA model, based on at least one of the risk data, the time code model, or the secret parameters, wherein the ETA model determines an estimated time of arrival (ETA) of the token to the provider; cryptographically binding, by the credentialing agent, the token, the risk data and the ETA model to generate a time code; and transmitting, the time code to at least one of the client, the provider, or a provider credentialing service, to facilitate a validation of the time code and the token to allow the client access to the service.

2. The computer implemented method of claim 1 , wherein the ETA model is a token validity time window.

3. The computer implemented method of claim 2, further comprising: monitoring, by the credentialing agent, the risk data, during the token validity time window, wherein the monitoring can take into account new factors or events that adjust the risk data.

4. The computer implemented method of claim 3, further comprising: determining, by the credentialing agent, based on the monitoring, that the risk data meets or exceeds a risk threshold; and invalidating, by the credentialing agent, at least one of the token, the risk data, the ETA model, or the time code.

5. The computer implemented method of claim 3, further comprising: determining, by the credentialing agent, based on the monitoring, that a risk score does not reach a risk threshold.

6. The computer implemented method of claim 2, further comprising: extending the token validity time window by the credentialing agent.

7. The computer implemented method of claim 1, wherein the ETA model is calculated using a service clock of the time code model.

8. The computer implemented method of claim 1 , wherein the time code is verified by the service, the provider, a provider service gateway web server, a T ransport Layer Security, or a provider credentialing service, to access the token.

9. The computer implemented method of claim 1 , wherein the credentialing agent is associated to the client.

10. The computer implemented method of claim 1 , wherein the risk data meets or exceeds a threshold, preventing the generating of a time code.

11. A system for continuous token monitoring and control, the system comprising: a provider that provides a web service; a credentialing service, associated to the provider, to manage service requests to the web service; a client, running on a user device, that requests access to the web service; and a credentialing agent, associated to the client, the credentialing agent configured to: receive, a token protection request from the client, to generate a time code for a token to allow client access to a service of a provider; receive, at least one of risk data, a time code model, or secret parameters associated with the token; generate, an ETA model, based on at least one of the risk data, the time code model, or the secret parameters, wherein the ETA model determines an estimated time of arrival (ETA) of the token to the provider; cryptographically bind, the token, the risk data and the ETA model to generate a time code; and transmit, the time code to at least one of the client, the provider, the web service, or a provider credentialing service.

12. The system of claim 11 , wherein the credentialing agent is further configured to: receive, token protection data that originated from the credentialing service, based on the token and an identifier of the web service.

13. The system of claim 12, wherein at least one of the credentialing agent or the client are further configured to: register the token protection data for further use.

14. The system of claim 12, wherein the token protection data comprises at least one of a remote clock, a time code model, a signing policy, a token signing certificate, a token validation service address, or secret parameters.

15. The system of claim 11 for continuous token monitoring and control, the system further comprising: a token issuance service, configured to: receive a service access request from the client to access the web service; authenticate the client; generate the token upon successful authentication; and transmit the token to the client.

16. The system of claim 11 , wherein the client is configured to: request access to the web service from at least one of a token issuance service, the provider, or the web service; receive the token from at least one of a token issuance service, the provider, or the web service; register the token; and request token protection from the credentialing agent.

17. The system of claim 11 , wherein the credentialing agent is at least one of an isolated enclave, a container, a cloud based app, or a computing device app.

18. The system of claim 11 , wherein the provider comprises a gateway web server.

19. The system of claim 11 , wherein the client is configured to: add the time code to an HTTP header; and transmit a request comprising the HTTP header and the time code to at least one of the credentialing service, the provider, or the web service.

20. A computer implemented method for authenticating a received token, comprising: receiving, by at least one of a provider of a service, the service, a credentialing service, a provider gateway, a provider web server, or a security stack, a request comprising a time code comprising a token and an HTTP header from a client; extracting, by the security stack, the time code from the request; validating, the time code, by the security stack; and based on the validating, processing, by at least one of the provider gateway, the provider web server, or the security stack, the token from the time code; and processing, by the service, the request to allow a client access to the service.