Abstract: Techniques are described herein for dynamically-tiered authentication, which allows the authentication tier (AT) associated with a session to be automatically downgraded based on the session satisfying one or more downgrade criteria. Automatically downgrading a session eliminates some authentication-based privileges for the session without eliminating all privileges for the session. A session satisfies downgrade criteria based on: an explicit request for session downgrading; client interaction with the application; and/or activity on the device on which the client runs. For example, if a client authenticates to a third AT, but only performs actions in the application that are associated with the first AT during a pre-defined amount of time, the AT associated with the session is automatically downgraded. The session is either downgraded from the third AT to the first AT, or downgraded in intervals until the current or more recently accessed tiers are consistent with the current AT of the session.

Abstract: Techniques are described herein for dynamically-tiered authentication, which allows the authentication tier (AT) associated with a session to be automatically downgraded based on the session satisfying one or more downgrade criteria. Automatically downgrading a session eliminates some authentication-based privileges for the session without eliminating all privileges for the session. A session satisfies downgrade criteria based on: an explicit request for session downgrading; client interaction with the application; and/or activity on the device on which the client runs. For example, if a client authenticates to a third AT, but only performs actions in the application that are associated with the first AT during a pre-defined amount of time, the AT associated with the session is automatically downgraded. The session is either downgraded from the third AT to the first AT, or downgraded in intervals until the current or more recently accessed tiers are consistent with the current AT of the session.

Abstract: Techniques are described herein for performing authentication, and also “eager” or “lazy” fetch of data, for restricted webpages based on the restricted webpages being associated with an authentication tier in an AASD registry. Inclusion of a restricted webpage in the AASD registry enables AASD-based authentication for the webpage. According to embodiments, information for a restricted webpage included in the AASD registry includes one or more of the following for the webpage: an identifier, an authentication level, allowed fields, eager fetch fields, one or more sources for one or more fields, etc. When information for a webpage is included in the AASD registry, that information is used to perform eager fetch for one or more fields of the webpage that are not associated with authentication requirements indicated in the AASD registry information, or whose authentication requirements are already fulfilled by the requesting client.

Abstract: Techniques are described herein for performing authentication, and also “eager” or “lazy” fetch of data, for restricted webpages based on the restricted webpages being associated with an authentication tier in an AASD registry. Inclusion of a restricted webpage in the AASD registry enables AASD-based authentication for the webpage. According to embodiments, information for a restricted webpage included in the AASD registry includes one or more of the following for the webpage: an identifier, an authentication level, allowed fields, eager fetch fields, one or more sources for one or more fields, etc. When information for a webpage is included in the AASD registry, that information is used to perform eager fetch for one or more fields of the webpage that are not associated with authentication requirements indicated in the AASD registry information, or whose authentication requirements are already fulfilled by the requesting client.

Abstract: Techniques are described herein for using special session identifiers to defer additional authentication steps (AAS) for at least some restricted application actions. A client session is associated with a special session identifier that is mapped to an authentication tier (AT) achieved for the session based on the satisfied authentication steps. Web servers that are enabled for AAS deferral include context information, which identifies a requested action, with session verification requests to an authentication service. The authentication service determines that AAS is required to perform an action when (a) the AT associated with the action is a higher-security tier than the AT associated with the session, or (b) the session is associated with an AT that is lower than the highest-security AT and there is no context information accompanying the request for session validation, in which case the authentication service assumes that the highest-security AT is required to perform the request.

Abstract: Techniques are described herein for performing authentication, and also “eager” or “lazy” fetch of data, for restricted webpages based on the restricted webpages being associated with an authentication tier in an AASD registry. Inclusion of a restricted webpage in the AASD registry enables AASD-based authentication for the webpage. According to embodiments, information for a restricted webpage included in the AASD registry includes one or more of the following for the webpage: an identifier, an authentication level, allowed fields, eager fetch fields, one or more sources for one or more fields, etc. When information for a webpage is included in the AASD registry, that information is used to perform eager fetch for one or more fields of the webpage that are not associated with authentication requirements indicated in the AASD registry information, or whose authentication requirements are already fulfilled by the requesting client.

Abstract: Techniques are described herein for using special session identifiers to defer additional authentication steps (AAS) for at least some restricted application actions. A client session is associated with a special session identifier that is mapped to an authentication tier (AT) achieved for the session based on the satisfied authentication steps. Web servers that are enabled for AAS deferral include context information, which identifies a requested action, with session verification requests to an authentication service. The authentication service determines that AAS is required to perform an action when (a) the AT associated with the action is a higher-security tier than the AT associated with the session, or (b) the session is associated with an AT that is lower than the highest-security AT and there is no context information accompanying the request for session validation, in which case the authentication service assumes that the highest-security AT is required to perform the request.

Abstract: Techniques are described herein for dynamically-tiered authentication, which allows the authentication tier (AT) associated with a session to be automatically downgraded based on the session satisfying one or more downgrade criteria. Automatically downgrading a session eliminates some authentication-based privileges for the session without eliminating all privileges for the session. A session satisfies downgrade criteria based on: an explicit request for session downgrading; client interaction with the application; and/or activity on the device on which the client runs. For example, if a client authenticates to a third AT, but only performs actions in the application that are associated with the first AT during a pre-defined amount of time, the AT associated with the session is automatically downgraded. The session is either downgraded from the third AT to the first AT, or downgraded in intervals until the current or more recently accessed tiers are consistent with the current AT of the session.

Abstract: Techniques are described herein for performing authentication, and also “eager” or “lazy” fetch of data, for restricted webpages based on the restricted webpages being associated with an authentication tier in an AASD registry. Inclusion of a restricted webpage in the AASD registry enables AASD-based authentication for the webpage. According to embodiments, information for a restricted webpage included in the AASD registry includes one or more of the following for the webpage: an identifier, an authentication level, allowed fields, eager fetch fields, one or more sources for one or more fields, etc. When information for a webpage is included in the AASD registry, that information is used to perform eager fetch for one or more fields of the webpage that are not associated with authentication requirements indicated in the AASD registry information, or whose authentication requirements are already fulfilled by the requesting client.

Abstract: Techniques are described herein for using special session identifiers to defer additional authentication steps (AAS) for at least some restricted application actions. A client session is associated with a special session identifier that is mapped to an authentication tier (AT) achieved for the session based on the satisfied authentication steps. Web servers that are enabled for AAS deferral include context information, which identifies a requested action, with session verification requests to an authentication service. The authentication service determines that AAS is required to perform an action when (a) the AT associated with the action is a higher-security tier than the AT associated with the session, or (b) the session is associated with an AT that is lower than the highest-security AT and there is no context information accompanying the request for session validation, in which case the authentication service assumes that the highest-security AT is required to perform the request.

Abstract: Techniques are described herein for dynamically-tiered authentication, which allows the authentication tier (AT) associated with a session to be automatically downgraded based on the session satisfying one or more downgrade criteria. Automatically downgrading a session eliminates some authentication-based privileges for the session without eliminating all privileges for the session. A session satisfies downgrade criteria based on: an explicit request for session downgrading; client interaction with the application; and/or activity on the device on which the client runs. For example, if a client authenticates to a third AT, but only performs actions in the application that are associated with the first AT during a pre-defined amount of time, the AT associated with the session is automatically downgraded. The session is either downgraded from the third AT to the first AT, or downgraded in intervals until the current or more recently accessed tiers are consistent with the current AT of the session.

Abstract: Techniques are described herein to handle situations in which multiple systems can change different copies of the same data item. Optimistic locking and time stamps are used to ensure consistency between the systems without incurring the performance penalties associated with two-phase commit. Specifically, when propagating a change to a data item from a first system to a second system, the second system compares the first system's “pre-update” value of the data item with its current value of the data item. If the pre-update value from the first system does not match the current value in the second system, then a conflict has occurred. Upon detecting a conflict, both systems use timestamps associated with the respective conflicting changes to determine which conflicting change “wins”. The winning change is applied by all systems whose changes did not win.

Abstract: Proof-of-Dynamic-Quorum is a consensus mechanism for blockchain networks that selects a dynamic quorum of nodes to validate a proposed block based on digital data included in the proposed block. In an embodiment, a request to add a proposed block to a blockchain is received by a node of a blockchain network. A composite key value is generated based on one or more values within the proposed block. Based on a composite-key-value-to-quorum-participants mapping that is indicated in one or more blocks that are already present in the blockchain, a validating quorum is determined to determine whether the proposed block is to be added to the blockchain. When each node of the validating quorum indicates that the proposed block is accepted, the receiving node writes the proposed block to the blockchain. Proof-of-Dynamic-Quorum enables real-world authority data to be considered when performing a consensus algorithm in a blockchain network.

Abstract: Techniques are described herein for performing authentication, and also “eager” or “lazy” fetch of data, for restricted webpages based on the restricted webpages being associated with an authentication tier in an AASD registry. Inclusion of a restricted webpage in the AASD registry enables AASD-based authentication for the webpage. According to embodiments, information for a restricted webpage included in the AASD registry includes one or more of the following for the webpage: an identifier, an authentication level, allowed fields, eager fetch fields, one or more sources for one or more fields, etc. When information for a webpage is included in the AASD registry, that information is used to perform eager fetch for one or more fields of the webpage that are not associated with authentication requirements indicated in the AASD registry information, or whose authentication requirements are already fulfilled by the requesting client.

Abstract: Techniques are described herein for dynamically-tiered authentication, which allows the authentication tier (AT) associated with a session to be automatically downgraded based on the session satisfying one or more downgrade criteria. Automatically downgrading a session eliminates some authentication-based privileges for the session without eliminating all privileges for the session. A session satisfies downgrade criteria based on: an explicit request for session downgrading; client interaction with the application; and/or activity on the device on which the client runs. For example, if a client authenticates to a third AT, but only performs actions in the application that are associated with the first AT during a pre-defined amount of time, the AT associated with the session is automatically downgraded. The session is either downgraded from the third AT to the first AT, or downgraded in intervals until the current or more recently accessed tiers are consistent with the current AT of the session.

Abstract: Techniques are described herein for using special session identifiers to defer additional authentication steps (AAS) for at least some restricted application actions. A client session is associated with a special session identifier that is mapped to an authentication tier (AT) achieved for the session based on the satisfied authentication steps. Web servers that are enabled for AAS deferral include context information, which identifies a requested action, with session verification requests to an authentication service. The authentication service determines that AAS is required to perform an action when (a) the AT associated with the action is a higher-security tier than the AT associated with the session, or (b) the session is associated with an AT that is lower than the highest-security AT and there is no context information accompanying the request for session validation, in which case the authentication service assumes that the highest-security AT is required to perform the request.

Abstract: Proof-of-Dynamic-Quorum is a consensus mechanism for blockchain networks that selects a dynamic quorum of nodes to validate a proposed block based on digital data included in the proposed block. In an embodiment, a request to add a proposed block to a blockchain is received by a node of a blockchain network. A composite key value is generated based on one or more values within the proposed block. Based on a composite-key-value-to-quorum-participants mapping that is indicated in one or more blocks that are already present in the blockchain, a validating quorum is determined to determine whether the proposed block is to be added to the blockchain. When each node of the validating quorum indicates that the proposed block is accepted, the receiving node writes the proposed block to the blockchain. Proof-of-Dynamic-Quorum enables real-world authority data to be considered when performing a consensus algorithm in a blockchain network.

Abstract: When a particular event record requires a particular service, but that service has failed for the event, an error record that includes an aggregate identifier (AgID) is stored for the event in an error queue. Storing an error record in the error queue causes the service to notify a remediation team to fix the failed event. All events with the AgID in the error record are put on hold and an error record is created for each of these events. The remediation team generates a fixed version of the event record and causes the system to retry the failed service for the event based on the fixed version. If the fixed version of the event is successfully processed, then any other events with the same AgID that have error records in the error queue, are routed in order of enqueue time through the event processor to be handled.

Abstract: Techniques are described herein to handle situations in which multiple systems can change different copies of the same data item. Optimistic locking and time stamps are used to ensure consistency between the systems without incurring the performance penalties associated with two-phase commit. Specifically, when propagation a change to a data item from a first system to a second system, the second system compares the first system's “pre-update” value of the data item with its current value of the data item. If the pre-update value from the first system does not match the current value in the second system, then a conflict has occurred. Upon detecting a conflict, both systems use timestamps associated with the respective conflicting changes to determine which conflicting change “wins”. The winning change is applied by all systems whose changes did not win.

Abstract: When a particular event record requires a particular service, but that service has failed for the event, an error record that includes an aggregate identifier (AgID) is stored for the event in an error queue. Storing an error record in the error queue causes the service to notify a remediation team to fix the failed event. All events with the AgID in the error record are put on hold and an error record is created for each of these events. The remediation team generates a fixed version of the event record and causes the system to retry the failed service for the event based on the fixed version. If the fixed version of the event is successfully processed, then any other events with the same AgID that have error records in the error queue, are routed in order of enqueue time through the event processor to be handled.