Transaction Signing Authentication Framework with Query Policy

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing authentication systems require clients to transmit exhaustive lists of authentication capabilities over networks, compromising privacy and efficiency, and often fail to manage random challenges effectively, leading to errors in authentication processes.

Innovation Solution

Implementing a query policy where a secure transaction server transmits a server policy to the client, allowing the client to identify a subset of accepted authentication capabilities, enabling multiple device provisioning and management, and automatically requesting new challenges when previous ones expire, while employing transaction signing to verify transaction integrity without maintaining session state.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If clients transmit exhaustive lists of authentication capabilities over networks, then authentication verification can be performed, but privacy is compromised and efficiency is reduced

Engineering Contradiction:
Improveauthentication verificationVSAvoidprivacy
Core Design Contradiction:
ReliabilityVSLoss of information

Solution Approach 1:

The patent extracts only the necessary authentication capability information from the client and transmits it to the server for verification, rather than transmitting exhaustive lists. This selective extraction maintains authentication reliability while minimizing privacy loss by sharing only what is strictly necessary.

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

The authentication process is segmented into distinct phases: capability advertisement, challenge generation, and verification. Each phase transmits only the specific information needed for that step, reducing overall information exposure while maintaining verification reliability.

Inventive Principle:
Principle #1Segmentation

2Adaptability or versatility

If exhaustive authentication capability lists are transmitted, then complete authentication options are available, but network bandwidth and processing time are consumed

Engineering Contradiction:
Improveauthentication optionsVSAvoidprocessing time
Core Design Contradiction:
Adaptability or versatilityVSLoss of time

Solution Approach 1:

The system performs partial action by transmitting only the subset of authentication capabilities that are currently relevant and accepted by the server, rather than all possible capabilities. This reduces processing time while maintaining adaptability to the server's requirements.

Inventive Principle:
Principle #16Partial or excessive action

Solution Approach 2:

The authentication capability transmission is made dynamic through the query policy mechanism, which adapts the transmitted information based on the server's current requirements and the client's accepted capabilities, optimizing the balance between versatility and efficiency.

Inventive Principle:
Principle #15Dynamics

3Loss of energy

If random challenges are not automatically renewed, then server resources are conserved, but authentication errors occur due to expired challenges

Engineering Contradiction:
Improveserver resourcesVSAvoidauthentication process
Core Design Contradiction:
Loss of energyVSReliability

Solution Approach 1:

The client implements a feedback mechanism that monitors challenge expiration and automatically requests new challenges when needed. This maintains authentication reliability without requiring continuous server resource allocation, as the server only responds when the client initiates a renewal request.

Inventive Principle:
Principle #23Feedback

Solution Approach 2:

The client performs self-service by automatically managing challenge renewal based on local timing information and server policies. This eliminates the need for server-side monitoring and resource allocation while maintaining authentication reliability through timely challenge updates.

Inventive Principle:
Principle #25Self-service

4Stability of the object's composition

If server maintains transaction state, then authentication continuity is ensured, but server storage and complexity increase

Engineering Contradiction:
Improveauthentication continuityVSAvoidserver-side storage
Core Design Contradiction:
Stability of the object's compositionVSDevice complexity

Solution Approach 1:

The patent extracts the session state management function from the server and relocates it to the client. The client maintains local state information and includes relevant state data in challenge requests, eliminating the need for server-side storage while ensuring authentication continuity through proper state tracking.

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

The client performs self-service by maintaining its own transaction state and challenge information locally. This eliminates server storage requirements while ensuring authentication continuity through client-side state management and proper inclusion of state data in communication protocols.

Inventive Principle:
Principle #25Self-service

Data Source

PatentUS9306754B2System and method for implementing transaction signing within an authentication framework
Publication Date: 2016.04.05 NOK NOK LABS INC
  • US9306754B2 patent drawing
  • US9306754B2 patent drawing
  • US9306754B2 patent drawing

AI summary

A system, apparatus, method, and machine readable medium are described for performing transaction signing within an authentication framework. For example, one embodiment of a method comprises: executing an online transaction between a first server and a client; providing transaction details of the online transaction to a second server; generating a signature over the transaction details using a key at the second server; transmitting an authentication request to the client with the signature and the transaction details; authenticating a user on the client to generate authentication data, the authentication data specifying whether the user was successfully authenticated on the client; and transmitting the authentication data, the transaction details, and the signature to the second server; using the transaction details and the key to validate the signature and using the authentication details to authenticate the client at the second server, wherein upon validating the signature and authenticating the client, the second server transmits a confirmation for the transaction to the first server.